RE: SQL Filling Job Log -- MIDRANGE-L

Thanks Vern,

Given the pressure I'm under to complete this project, and since I view the solutions you provided as reactive vs proactive (the solution given being to remove the message after its been written vs preventing it from being written), I've switched the service program to use native I/O. (An easy change really.) I wasn't aware of STRWCH however, it's now on my list of topics to learn more about.

This job log issue has been a major stumbling block in getting our file encapsulated service programs to use SQL. I've talked to our team and I really don't see a different type of test environment being created in the near future. I don't feel that I'm in the majority with the want for suppressing job log entries. I asked for it as an option on the RPG On-Error opcode and was told it wasn't going to happen. I do use message removal on occasion, but am not a fan.

-Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vernon Hamberg
Sent: Friday, June 07, 2013 1:31 PM
To: Midrange Systems Technical Discussion
Subject: Re: SQL Filling Job Log

Kurt

A couple crazy ideas - how about adding a watch for these messages?
STRWCH is the command, if you've not looked at it before.

My thought is, you can delete a message that just arrived, I would think.

Each watch can be set for up to 5 message IDs, and you can specify generic message IDs.

When any of the messages appears on the job log or some other place specified, the watch program is called. You get to do what you need to then.

Jobs that are being watched can also be specified with generic values.

I don't know - maybe!

Another idea is to bracket the job with the technique of walking through all messages between the SNDPGMMSG with message key. It could be done for only the programs with SQL processing. Again, unwanted messages can be received with DLT(*YES). Again, you'd need to know the message IDs you want not to see.

HTH
Vern

On 6/7/2013 12:13 PM, Gary Thompson wrote:

Yea, that's what I *thought* I had been able to do - hopefully someone else helps with this

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Anderson, Kurt
Sent: Friday, June 07, 2013 11:09 AM
To: Midrange Systems Technical Discussion
Subject: RE: SQL Filling Job Log

*No suppresses SQL messages from going to the job log when STRDBG is not active.

I'm trying to find a way that I can (ideally optionally) suppress SQL messages from going to the job log when STRDBG is active.

In my test I processed 130k records which resulted in 70k inserts.
The old job log was 40 pages.
Now, there are 483 job logs that are 338 pages, plus one final job log that is 21,394 pages. That's a total of 184,648 pages.

-Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gary Thompson
Sent: Friday, June 07, 2013 11:56 AM
To: Midrange Systems Technical Discussion
Subject: RE: SQL Filling Job Log

Kurt.
You are right on target. From *memory* I think *NO for that setting should suppress . . . HTH
--
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.