RE: Calling a stored procedure from a VB6 program using the DB2 database driver -- MIDRANGE-L

Mark,
The other complication in your case is how the request from VB6 gets "serviced" - the subsystem handling
the VB6 request will assign that to either an existing job or start a new job depending on "current conditions",
so this is another "shotgun" issue where the JOBD for all those jobs may need to be changed for a few hours
or a day to catch the problem and get a fix.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Walter
Sent: Thursday, July 30, 2015 7:54 AM
To: Midrange Systems Technical Discussion
Subject: RE: Calling a stored procedure from a VB6 program using the DB2 database driver

Yea, that's what I thought. I did a CHGJOB to the servicing job and still didn't get any more information in the job log.

Mark Walter

Business to Business Data Integration Specialist Certified IBM System i Specialist Paragon Consulting Services, Inc.
mwalter@xxxxxxxxxxxxxxx
717-764-7909 ext. 20

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gary Thompson
Sent: Thursday, July 30, 2015 9:52 AM
To: Midrange Systems Technical Discussion
Subject: RE: Calling a stored procedure from a VB6 program using the DB2 database driver

Mark, what I've typically done is change a job description or change to use a particular job description to get the message logging I want, among other job attributes.

The following is just the part of the iSeries Change Job Description command CHGJOBD that sets job message logging:

Message logging:
Level . . . . . . . . . . . . 4 0-4, *SAME
Severity . . . . . . . . . . . 00 0-99, *SAME
Text . . . . . . . . . . . . . *NOLIST *SAME, *MSG, *SECLVL, *NOLIST

As you can see, there are three parts to a job's message logging:

Level:
4 is the most detailed and common for problem resolution situations

Severity:
0 (zero) means messages that provide information and are in no-way associated with an error will be included (very verbose/detailed)

Text:
*SECLVL means that each message included in the log includes second- level text. This is the second "dimension" to getting a "verbose" log

Note: Verbose job logs should be used only as required and your admin should be aware of the need to manage/clean-up logs to avoid excessive disk use.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Walter
Sent: Thursday, July 30, 2015 7:33 AM
To: Midrange Systems Technical Discussion
Subject: RE: Calling a stored procedure from a VB6 program using the DB2 database driver

He's not sure how to do that. Can you be more specific.

Thanks,

Mark Walter

Business to Business Data Integration Specialist Certified IBM System i Specialist Paragon Consulting Services, Inc.
mwalter@xxxxxxxxxxxxxxx
717-764-7909 ext. 20

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gary Thompson
Sent: Thursday, July 30, 2015 9:22 AM
To: Midrange Systems Technical Discussion
Subject: RE: Calling a stored procedure from a VB6 program using the DB2 database driver

Mark,

If you can identify the QRWTSRVR job servicing the request, then I think a "verbose" log of that job would have the details of the object(s) to which "you" don't have access (running without *allobj).

Your admin should be able to set your job up so the job will produce a "verbose" log, which means you should see a very detailed list of all errors and system messages produced by the iSeries server, and get a list of any objects to which you do not have access.

I'm not sure, but the change to get a verbose job log may require a "shotgun" effort because I don't know that your admin can know in advance which of the QRWTSRVR jobs will handle your particular request. If I remember
these are subsystem "pre-start" jobs and it's kind of a first come/first served resource assignment process . . .

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Walter
Sent: Thursday, July 30, 2015 6:47 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Calling a stored procedure from a VB6 program using the DB2 database driver

Hello all,

I have a stored procedure on an iSeries that I created. I'm trying to fire that SP from a VB6 program (Don't ask), using the Microsoft OLE DB Provider for DB2. When I log into the application using my user id, I'm getting an error that I don't have authority to "something". The message is not very clear as to what I don't have access. I know I have authority to the program behind the procedure. I'm the owner and it has *public *all. I'm thinking it's one of the underlying programs or files that tells the iSeries how to convert a SP to a program, for lack of a better explanation.

I can find the QRWTSRVR job that is servicing the request. When the admin gives me *allobj authority (I'm a consultant here), the procedure works fine and I can see the results of the job in the joblog of the QRWTSRVR job. But, that joblog gives me no clue as to what I don't have access.

Any ideas on how I can lock this down?

Thanks,

Mark Walter

Business to Business Data Integration Specialist Certified IBM System i Specialist Paragon Consulting Services, Inc.
mwalter@xxxxxxxxxxxxxxx<mailto:mwalter@xxxxxxxxxxxxxxx>
717-764-7909 ext. 20

--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6081 / Virus Database: 4392/10331 - Release Date: 07/29/15
--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6081 / Virus Database: 4392/10331 - Release Date: 07/29/15
--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.