Can I change default values for printer writers.

[Guest.Visitor]

Most of our printers are laser printers connected via Client Access print sessions. Every night when our 400 IPLs each writer's MESSAGE OPTION gets reset to *INQMSG. Since we can't change paper we would like the MESSAGE OPTION to default to *NOMSG. It would be best if this could be done for selected printer writers - but I would do it globally if I have to, as we only have a handfull of line and dot matrix printers. Just in case it is not clear, this command makes the desired change: CHGWTR WTR(&PRINTER) FORMTYPE(*SAME *NOMSG) Thanks, John

[cwscholbe@dstsystems.com]

Can't you update your STARTUP PGM and add the statements you want? Then whenever you IPL, these statements are executed and you don't have to do it manually. Chris

[Guest.Visitor]

I havn't seen a practical way to change the writers at IPL since the writers must be active to run a CHGWTR command. John

[cwscholbe@dstsystems.com]

Can you use an ASJ in the QSPL SBS? The CLP that you invoke could delay long enough for the writers to become active? OR do they not become active until they are used, the first time?

[Guest.Visitor]

The writers don't become active (and can be changed) until the corresponding client access sessions are started. John

[Guest.Visitor]

John, I believe you are probably experiencing this every time a Client Access session is re-opened. The command default for STRPRTWTR is *INQMSG. You could change the default to whatever you wanted to. What I would do is change it, stop and start a C/A session printer, and then check the writer and see if it is what you wanted. Be aware that this will affect all writers on your entire system. HTH Scott

[Guest.Visitor]

<blockquote><tt>I believe you are probably experiencing this every time a Client Access session is re-opened. No, the CHGWTR command changes remain in affect until the next IPL even if the session is closed and re-opened. </tt></blockquote> >The command default for STRPRTWTR is *INQMSG. You could change the default to whatever you wanted to Ahh, how is this done? John

[Guest.Visitor]

John, I'll rip off Scott's suggestion in a couple of ways: To change a command's default use the ChgCmdDft command. One other (better?) way would be to modify your AS/400's start up program. It's the equivalent of Autoexec.bat. <font color="red">Don't mess with the start up program unless you are real sure of your CL programming capabilities.</font color> Find out the name of your startup program by running the command DspSysVal StrUpPgm. This will provide the name of the program used during startup. If someone has modified your startup it WON'T be QSYS/QSTRUP. To modify the startup program do a RtvCLSrc command specifying the program as QSys/QStrup - putting the resulting source member in a convenient source file (QGPL/QCLSRC) and giving it a different name (MODSTRUP). There is a place in the startup that checks to see if the writers should be started and then does start them. You could either modify the StrPrtWtr command to use the command parameter you need -or- individually start the affected writers first specifying the proper command parameters. I would also suggest you reduce the number of IPL's you are performing. A CISC machine OS/400 V3R2 and earlier would only need to be IPL'd weekly at most and RISC machines could even be on an IPL only as necessary schedule. Bill

[Guest.Visitor]

Thanks Bill. John, I just recreated your scenario. You are correct, it does restart the writer with *nomsg. To change a command default for your situation, CHGCMDDFT CMD(STRPRTWTR) NEWDFT('FORMTYPE(*ALL *NOMSG)') this should do it. I gave it a test run and it seems to be working. I would probably go with the startup program advice that Bill mentioned. This way you aren't changing a command default. Not sure if it will work since the C/A sessions won't be active after an IPL. Another option would be the system reply list. But it would be easier to do the change command default thingy. Scott (Slipped this one in right before John could respond)

[Guest.Visitor]

<blockquote><tt>>I believe you are probably experiencing this every time a Client Access session is re-opened. >No... </tt></blockquote> I take this back. I had originally researched this a couple of years ago and I'm not quite remembering the details correctly. 5 minutes later... Well, I just saw Scott's post (slipped in before this one) I was pretty sure that the *NOMSG remained - but at the moment it is not (I'm on 4.3).