× 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.


  • Subject: RE: Editing Startup program on as/400
  • From: Neil Palmer <npalmer@xxxxxxxxxxx>
  • Date: Sat, 20 Jun 1998 03:04:36 -0500

I recommend always adding the following line to the beginning of your
startup program:

CHGJOB LOG 0 *SECLVL) LOGCLPGM(*YES)

then if you have a problem do WRKJOB QSTRUPJD to find the joblog.
Also check QSYSOPR message queue and do DSPLOG QHST for the time the
startup program was running.

If it's an authority problem to commands, I always recommend the startup
program should be owned by QSECOFR, and be created with USRPRF(*OWNER)



Neil Palmer                                AS/400~~~~~      
NxTrend Technology - Canada   ____________          ___  ~     
Thornhill, Ontario,  Canada   |OOOOOOOOOO| ________  o|__||=   
Phone: (905) 731-9000  x238   |__________|_|______|_|______)   
Cell.: (416) 565-1682  x238    oo      oo   oo  oo   OOOo=o\   
Fax:   (905) 731-9202       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
mailto:NPalmer@NxTrend.com    AS/400  The Ultimate Business Server      
http://www.NxTrend.com

> -----Original Message-----
> From: Chuck Lewis [SMTP:CLEWIS@IQUEST.NET]
> Sent: Tuesday, June 16, 1998 10:58 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: Editing Startup program on as/400
> 
> Mike,
> 
> Are you saying that the delay job (from STRTCP to STRHOSTSVR) is NOT
> necessary and that the problem is TOTALY the authority deal ?
> 
> The way that whole deal works is weird/a pain...
> 
> When Host Servers/Services stops (i.e. at IPL) I get messages about
> all of the jobs ending; but NEVER get any information that they
> started when they start AFTER IPL...
> 
> I also never see any job logs or anything in the start up job log...
> 
> I know you can look at the active jobs and find the stuff,  but it
> seems inconsistant with the way other stuff works...
> 
> Chuck
> 
> Mike Shaw wrote:
> 
> > Gary,
> >
> > It really has nothing to do with the changes you made to the startup
> pgm...It's the authority needed to run STRHOSTSVR that is causing you
> to start it manually.  Your startup program runs under the user QPGMR.
> You will have to edit the object authority for STRHOSTSVR and give
> QPGMR *USE rights to it.  Once you have done that, it should run just
> fine via the startup program.
> >
> > HTH
> >
> > Mike Shaw
> >
> > ----------
> > > Sorry for the wrong subject line.  Here's the real one.
> > > Gary Lehman
> > > Programmer Analyst
> > > Missouri Consolidated Health Care Plan
> > >
> > >               -----Original Message-----
> > >               From:   Gary Lehman
> [mailto:Gary_Lehman@mail.mchcp.org]
> > >               Sent:   Tuesday, June 16, 1998 2:25 PM
> > >               To:     'MIDRANGE-L@MIDRANGE.COM'
> > >               Subject:        RE: Passing numeric fields to COBOL
> program
> > >
> > >               Hello,
> > >
> > >               This may be delving deep into the system, but has
> anyone
> > > ever edited the
> > >               QSTRUP program in QGPL library?  It's the system
> start up
> > > and I had to
> > >               modify it to call our START program so as to start
> TCP/IP
> > > and do STRHOSTSVR
> > >               whenever we bring it down.  However, lately it seems
> like
> > > after it comes
> > >               back up TCP/IP comes up but the Host servers do not.
> > > Consequently, I have
> > >               to start the servers manually.  Does anyone know
> where the
> > > messages go for
> > >               QSTRUP so I can look at them?  I'd like to see if I
> could
> > > find out if its
> > >               actually hitting certain parts of the CL.
> > >
> > >               Thanks
> > >               Gary Lehman
> > >               Programmer Analyst
> > >               Missouri Consolidated Health Care Plan
> > >               +---
> > >               | This is the Midrange System Mailing List!
> > >               | To submit a new message, send your mail to
> > > MIDRANGE-L@midrange.com.
> > >               | To subscribe to this list send email to
> > > MIDRANGE-L-SUB@midrange.com.
> > >               | To unsubscribe from this list send email to
> > > MIDRANGE-L-UNSUB@midrange.com.
> > >               | Questions should be directed to the list
> owner/operator:
> > > david@midrange.com
> 
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.