|
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. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.