RE: System value QSTRPRTWTR

Rob,

It's really not that difficult to just use your own startup program.  I 
typically do a RTVCLSRC on QSTRUP, copy it to a new member, MEAASTRUP for 
example, and add any additional code I need.  When I add the code, I make sure 
it stands out from the IBM code.  I compile it to use adopted authority.

Then just change the QSTRUPPGM system to use my custom program.

When I upgrade, reconciling any changes to IBM's QSTRUP is pretty simple.

Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of rob@xxxxxxxxx
> Sent: Wednesday, January 19, 2005 11:40 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: System value QSTRPRTWTR
> 
> 
> Because of an earlier thread.  The supplied QSTRUP cannot 
> start most of 
> our writers because of the security on them.  QSTRUP runs 
> under QPGMR and 
> that will not have access to most of these output queues.  I 
> looked at the 
> options of 
> - Modifying the job description that QSTRUP runs
> - Changing the QSYS/QSTRUP program to do it's own authority adoption
> - etc
> Using my own adopted program to call IBM's, then start my 
> writers, seemed 
> most likely to:
> - Not miss any enhancements that IBM supplies to QSYS/QSTRUP
> - Not get the job description, nor the authority whacked up 
> when putting 
> on a new release.
> 
> I will not conditionally call QSYS/QSTRUP.  But mine will have the 
> necessary authority.  And will be the program listed in QSTRUPPGM.
> 
> Rob Berendt
> -- 
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> 
> 
> 
> 
> "Steve McKay" <nospammers1@xxxxxxxxx> 
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 01/19/2005 11:21 AM
> Please respond to
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> 
> 
> To
> midrange-l@xxxxxxxxxxxx
> cc
> 
> Subject
> Re: System value QSTRPRTWTR
> 
> 
> 
> 
> 
> 
> Rob -
> 
> Not sure why you're wanting to replicate IBM's code in your 
> version of 
> QSTRUP.  Are you going to conditionally call QSYS/QSTRUP?  If 
> so, I would 
> infer that your QSTRUP will run at times other than IPL time. 
>  If not, why 
> 
> would you want to start (or not start) printers after you 
> called IBM's 
> QSTRUP (which performs the same function)?
> 
> Just Curious,
> 
> Steve
> <rob@xxxxxxxxx> wrote in message 
> news:OFA566D81E.BE0E06CA-ON05256F8E.0052FC50-05256F8E.00537DE5
> @dekko.com..
> .
> > Got this question about a system value and wasn't getting a 
> response to 
> a
> > thread on the security list.  Since it started wavering off 
> to system
> > values I thought I'd cross post it here.
> >
> > I will have my own QSTRUP call the one in QSYS first.  Then it will
> > execute it's thing, but with adopted authority.  This way I 
> will get any
> > new updates that IBM decides to add in QSYS/QSTRUP, and, if 
> I put on a 
> new
> > release I don't have to worry about changing any job descriptions,
> > changing the authority on QSYS/QSTRUP, etc.
> >
> > I have one question about this.  I planned on using the 
> technique that 
> IBM
> >
> > uses in their QSTRUP to start writers.
> >     QSYS/RTVSYSVAL SYSVAL(QSTRPRTWTR) RTNVAR(&STRWTRS)
> >     IF COND(&STRWTRS = '0') THEN(GOTO CMDLBL(NOWTRS))
> >     CALL PGM(QSYS/QWCSWTRS)
> >     MONMSG MSGID(CPF0000)
> > NOWTRS:
> >
> > So my code is a copy of the above, preceded by CALL QSYS/QSTRUP.
> >
> > But if I previously called QSYS/QSTRUP I want to make sure that 
> QSTRPRTWTR
> >
> > is not reset by that.  So, at what point does that get 
> reset?  This is 
> not
> >
> > a system value you can do CHGSYSVAL on.  Just want to make 
> sure that if 
> I
> > am doing some special IPL that I don't start the printer writers
> > unnecessarily.
> >
> > Rob Berendt
> > -- 
> > Group Dekko Services, LLC
> > Dept 01.073
> > PO Box 2000
> > Dock 108
> > 6928N 400E
> > Kendallville, IN 46755
> > http://www.dekko.com
> > -- 
> > 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.
> 
> 
> -- 
> 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.
> 
>