SQL / DFU logs

[Guest.Visitor]

Carl, Change the value of the Audit Report parameter to N. Doug.

[Guest.Visitor]

OK - but where do I find this parameter? and will this be a global change? It seems any user that performs the action gets a joblog

[Guest.Visitor]

These parameters are seen on option #2 (create), or option #3 (change), on the STRDFU menu. You need to locate the DFU program being executed, and then take option #3 to modify this parameter. To create new DFU programs, use option #2, and specify the appropriate response for this parameter. Doug.

[Guest.Visitor]

Sorry ! I can't find the parameters you are mentioning - on STRDFU opt2 or 3 doesn't give that option. When I want to perform UPDDTA I cant see it either - or when I execute STRSQL. Am I missing something?

[Guest.Visitor]

Here is specifically what I did: At a command line, type STRDFU and press ENTER. Take option #3 (three and ENTER) to change a program. At the prompt screen, type the name of the DFU program and library it resides in and press ENTER. The next screen that appears is titled: "Define General Information/Indexed File" That is the screen with the parameters I am referring to. The Audit Report parameter is the third one I see. Let me know if this works. Doug.

[Guest.Visitor]

Not sure if we are in the right area here. the guys are using UPDDTA and STRSQL - these are then producing the logs. Sorry iff I confused you!!

[Guest.Visitor]

OK. Gotcha. Here is what I'd do: 1. You could create a DFU program for the file you are updating, and use that program to update the file, rather than UPDDTA. I think you could put the CHGDTA command with the new DFU program name in place of the UPDDTA command. 2. Identify the printer file the logs are going to. Create a new OUTQ that will hold these jobs, but do not assign a printer to them. Use an OVRPRTF command before the DFU or STRSQL command to have those logs sent to that OUTQ. Use a DLTOVR to remove the override after the changes are completed. 3. Same as #2, but instead of sending the output to another OUTQ, just change the HOLD parameter to *YES. This will place the print job in the printer queue, but it will not print. In any event, these print jobs will need to be purged periodically. I do not know how to prevent these jobs from being produced (except if you try #1 above), but these directions will prevent the job from being printed. Hope this helps! Doug.

[bharder@nlrha.ab.ca]

You really ought to consider the change logs to be an advantage. We do! We route all our logs to output queue QEZJOBLOG and then automatically age them with a tool from help/systems. You don't need such logs often but they can be real handy in a pinch. If a client, or a programmer, has an "Oh No, What Have I Done!" moment, the logs will tell you. They can often allow you to reverse the changes without having to restore from backup. Change logging is a key step in creating auditable systems!

[Guest.Visitor]

Hi , It seems that ' recently' whenever anyone performs a DFU or SQL a log of the changes/updates is produced and prints off on the default printer. does anyone know how I can stop these logs being produced? TIA Carl

[Guest.Visitor]

Saving the logs does sound a good idea - but - how do I direct them to another outupt queue?