Re: NEWI Daemon & IPLing - Update - DO NOT TRY IT -- BPCS-L

Hi Dennis,

I can tell you are frustrated. In fact, you actually changed *more* that one
thing by IPLing your system - you changed the user profile who starts BPCS
too - and that was your main problem.

My concern is with correcting your posting is that truth be spread here on
the forum and not 'voodoo computer science' where cause and effect are not
completely understood but people say to all 'don't do this or that' because
they *think* it caused something bad to happen, but as of yet have no proof.

Telling everyone not to change authority on those 2 objects and to say that
BPCS won't run because of it is still NOT TRUE.  BPCS may not have run on
your system today, but it had nothing to do with you changing those objects
per se - you merely got 1 step further down the road to what is still a dead
end and it confused you.

BPCS stopped running after IPLs of your system because your system start up
submits the Newi daemon with a user profile who has insufficient authority.
You merely got 1 step further in BPCS by changing the objects to allow QPGMR
to use them when the daemon launched - this caused the daemon to launch off,
when previously it did not launch. But just because it launched, it did not
mean the daemon could spawn BPCS applications when a user logged in. It
still lacked authority to switch to the user profile logging into BPCS
because QPGMR did not have authority to change the user profile signing onto
the system.

In this case, I think you would have been better served by calling SSA
Helpline to get more complete advice over the phone rather than trying to
solve this on the forum.

When I said in my other posting this AM that you could change the
authorities back on those objects I *meant* you could change them back to
the way you *THINK* will make BPCS fail - and I guarantee you 100% that it
will NOT make BPCS fail. If you had left the objects alone and merely
started the daemon again with the profile copied from QSECOFR, it would have
worked just fine.

If BPCS daemons are running with the right user profile who has sufficient
authority, there is just no issue at all with what other user profiles have
authority to those objects.

Something to remember is that when the PC hangs on a BPCS job, the first
thing you should do is to view the stopped BPCS server job and look for
error messages or try to find job logs - these would have likely shown
something like "Could not change to user" or something similar (and
potentially cryptic, but useful when telling others about the problem to
assist in debugging it).

> I just didn't think it was a big deal to change the authority on the
>QSYS/QSYGETPH object.  The
> error I was getting just didn't lead me to think that it was a big
>deal.  Lesson learned.

It is not a big deal to change that authority the way that you changed it.
Please do not learn the wrong lesson. The big deal is that apparently your
IPL and system start up was not thoroughly tested to the point of logging
into and running BPCS - that is the better lesson.

There is no example of how to create an autostart job in the BPCS Redbook -
I think that was a system work management function that was assumed was
covered under existing IBM documentation.

I also recommend that you do not wait to read the entire Redbook before you
try to find things in it - open in it on the internet and use the
search/find tools provided by word processing programs to look up key words
on what you are having problems with - don't wait to read the entire thing
on paper - use it as a web reference until you have a chance to look at it
all.

Autostart jobs are fairly easy to figure out and do - I suggest you try a
very simple one to get the hang of it before going for the whole thing with
live BPCS. Maybe others here have example programs they want to share.

Note that SSA Helpline will not assist in custom programming and system
configuration stuff (ie they don't write or debug your programs for you).
But they can certainly figure out why a job that is trying to start the
daemons using the SSA-supplied command won't run a BPCS job, and there are
also lots of hits on OGS that describe what you had happen (if you also view
the AS/400 side for error messages).

Also note that the below is not to be taken as gospel, and hopefully I have
not forgotten too much!! :-) So, caveat emptor with the following brief
example I have come up with quickly:


GO CMDJOB lists the commands - you can press F1 here and find some help for
what to do for autostart jobs.


                        Add Autostart Job Entry (ADDAJE)

 Type choices, press Enter.

 Subsystem description  . . . . .       SUBSYSN          Name
   Library  . . . . . . . . . . .     QGPL   Name, *LIBL, *CURLIB
 Job name . . . . . . . . . . . .     STARTUP            Name
 Job description  . . . . . . . .   STARTUP Name, *SBSD
   Library  . . . . . . . . . . .            BPCSSTART     Name, *LIBL,
*CURLIB

The job name and library are merely the name of a job description that will
be used when the subsystem starts up, and the name the submitted job will be
given. Use CL or whatever you like for the program. I recommend CL in this
case for ease of use. In your JOBD, make sure that the user profile I
mentioned is used (one with *ALLOBJ and password *NONE).


WRKSBS and option 5 and option 3:

                         Display Autostart Job Entries
                                                             System:
SSAXXXXX
 Subsystem description:   SUBSYSN       Status:   ACTIVE


 Job            Job Description     Library
 STARTUP          STARTUP           BPCSSTART


_________________________________________

WRKOBJPDM on STARTUP:


 Library . . . . .   BPCSSTART          Position to . . . . . . . .
                                      Position to type  . . . . .

 Type options, press Enter.
   2=Change       3=Copy        4=Delete      5=Display       7=Rename
   8=Display description        9=Save       10=Restore      11=Move ...

 Opt  Object      Type        Attribute   Text
      STARTUP     *PGM        CLP         Startup job for SUBSYSN subsystem
      STARTUP     *JOBD                   SUBSYSN Subsystem Startup Job

_____________________________________________

And the JOBD is key - it has everything including the user profile to use
listed out (OK - this is where you put the guy with *ALLOBJ and Password
*NONE) and what program to call is listed in the Request data section with a
library-qualified call to the program in question:

Job description:   STARTUP        Library:   BPCSSTART

User profile . . . . . . . . . . . . . . . . . . :   DAEMON
CL syntax check  . . . . . . . . . . . . . . . . :   *NOCHK
Hold on job queue  . . . . . . . . . . . . . . . :   *NO
End severity . . . . . . . . . . . . . . . . . . :   30
Job date . . . . . . . . . . . . . . . . . . . . :   *SYSVAL
Job switches . . . . . . . . . . . . . . . . . . :   00000000
Inquiry message reply  . . . . . . . . . . . . . :   *RQD
Job priority (on job queue)  . . . . . . . . . . :   5
Job queue  . . . . . . . . . . . . . . . . . . . :   QBATCH
 Library  . . . . . . . . . . . . . . . . . . . :     QGPL
Output priority (on output queue)  . . . . . . . :   5
Printer device . . . . . . . . . . . . . . . . . :   *USRPRF
Output queue . . . . . . . . . . . . . . . . . . :   *USRPRF
  Library  . . . . . . . . . . . . . . . . . . . :

Routing data . . . . . . . . . . . . . . . . . . :   QCMDI

Request data . . . . . . . . . . . . . . . . . . :   call bpcsstart/startup



Your CL program would start the daemons (start both ALAUNCH and NEWI if you
want) to the required ports using the SSA commands or program calls, and add
some sort of error handling to send e-mails to yourself if it fails or what
have you, if you want. I suggest testing it and trying to force errors to
occur to make sure you are covered by your error handling, and that you know
what to expect to see if the job fails.

Remember that an autostart job then gets called WHENEVER the subsystem
restarts - most people like this because it also assists starting BPCS again
after backups are done (if you end your BPCS subsystem to do a backup) - so
you will also need to find your job scheduled entries or anything you did
around ending/restarting daemons for backups previously, and make sure those
won't conflict with the new changes you are making (like accidentally trying
to start daemons from 2 different jobs to the same port at once). And of
course, test it before the next time you do it 'live'! I didn't test this so
sorry ahead of time if I left out some bits!

 :-)

Hope this helps get you on track,

Genyphyr Novak
SSA



-----Original Message-----
From: Dennis Munro <DMunro@badgerminingcorp.com>
To: 'BPCS-L@midrange.com' <BPCS-L@midrange.com>
Date: Monday, January 17, 2000 4:43 PM
Subject: RE: NEWI Daemon & IPLing - Update - DO NOT TRY IT


>Genyphyr,
>
><snip>
>What you say about the object authority change causing BPCS not to run is
>simply NOT TRUE.
><snip>
> When you don't understand all that happens behind the scenes, I
>still stand by my statement.
> All I did was change the authority to QPGMR for the object
>QSYS/QSYGETPH to *ALL & then
>IPLed the system.  And by doing that, my BPCS system would not run & that
is
>what I said.
>It would not run - period.  You would click on a menu option & it would
just
>sit there.
>
><snip>
> You can change the authorities on those objects back to what you had
>them
> this AM, and BPCS will work just fine.
><snip>
> That's exactly what I did.
>
><snip>
> When you start the daemon manually - who runs it - not QPGMR, right?
>
> Probably yourself, or someone who is copied from QSECOFR?
><snip>
> You are correct, it was my profile & it was copied from QSECOFR.
>How did you guess?<vbg>
>


+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---