× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Kurt

Yeah, as I offered the idea, I considered that it would take time to clean things up - better to be ahead of the game.

Message removal using the message key techniques is sometimes the only way to clean up a log, since some messages come from outside the main stream - I don't have a better way from fighting a cold to say it. It's also a great way to check for messages of any kind in the process.

Watches are very cool - Bruce Vining has sessions on this at COMMON and other places, probably an article or 2 out there. The nice thing is, they add almost nothing to processing until there is a match - the check for a watch is always done by the message-handling tasks for every message that is sent.

I must admit to a bit of surprise at the notion of using STRDBG to prevent updates to production files. I hope I stated that rightly - I'd have to find your original post, again, to see if this is in a true production setting, where I see no need for this - so I must be confused!!!

Be well
Vern

On 6/7/2013 1:52 PM, Anderson, Kurt wrote:
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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.