Re: CISC to RISC problems? It's still happening!

[rob@xxxxxxxxx]

Also, IBM always hoses up authorization lists when restoring to a different
box.  Anyone with a production/development box scenario can testify to
that.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                      "Mark Waterbury"
                      <mark.s.waterbury@worldn        To:       
<midrange-l@midrange.com>
                      et.att.net>                     cc:
                      Sent by:                        Fax to:
                      midrange-l-admin@midrang        Subject:  Re: CISC to 
RISC problems? It's still happening!
                      e.com


                      10/08/2002 08:40 AM
                      Please respond to
                      midrange-l






Hi, Rick:

Depending on the setting of certain system values (some of which
did not exist yet in V2Rx), OS/400 will "revoke public authority"
to any *PGMs that "adopt authority". This could cause some of
the kinds of problems you describe... In particular, take a look at
settings for: QALWOBJRST, QVFYOBJRST, QFRCCVNRST,
and QUSEADPAUT.  Also, you should have restored all of the
objects/libraries using QSECOFR, and specified the parameter:

    ALWOBJDIF(*ALL)

on the restore commands.

You probably should also run the RSTAUT, because otherwise,
the "private authorities" do not get saved/restored with a normal
SAVOBJ/RSTOBJ or SAVLIB/RSTLIB (sadly).

You might want to run some queries over some outfiles to see if
any of the *PGMs in your production libraries have *PUBLIC
rights of *EXCLUDE.

Do you still have the old CISC box to compare to? That way,
you could create an outfile on the CISC box of which programs
adopt authority, and have what security settings, and you could
even write a CL program to read this outfile and apply those
security settings on the new machine.

Good luck,

Mark S. Waterbury

----- Original Message -----
From: "Rick Rayburn" <the400man@hotmail.com>
To: <midrange-l@midrange.com>
Sent: Tuesday, October 08, 2002 5:40 AM
Subject: Re: CISC to RISC problems? It's still happening!


> Simon -
>
> Remember: there were no problems with crtdupobj OR the running of that
> program PRIOR to the conversion: are object rights re-established in
full?
> Do they need a RSTAUT command? Also, the program abending was executed
> exactly the same way (from a menu option) as before. I'm looking for some
> known problem with parameter handling that may have been previously
> identified with other conversions of this type.
>
> Thanks again.
>
>
> >From: "Simon Coulter" <shc@flybynight.com.au>
> >Reply-To: midrange-l@midrange.com
> >To: midrange-l@midrange.com
> >Subject: Re: CISC to RISC problems? It's still happening!
> >Date: Tue, 08 Oct 02 11:48:05 +1000
> >
> >
> >Hello Rick,
> >
> >You wrote:
> > >1. An RPG program is now blowing up at *entry with "reference to
unpassed
> > >parameter"...a program which ran consistently for more than 5 years
> >without
> > >an abend! There is a #PARMS statement checking the pass so how could
this
> > >conversion have suddenly caused this blow-up?
> >
> >We'd need to see the code to be certain.  It is possible that some OS
> >changes
> >have resulted in breaking the converted program, but it is more likely
that
> >the
> >original program had a latent defect which is only now manifesting.
> >
> > >2. object authorities. they could not run a crtdupobj...authority
> >problem.
> > >When checking the object, *PUBLIC was *change. WHen he changed that to
> >*ALL,
> > >it worked. There was, again, no problem prior to the conversion. I do
not
> > >know if they ran RSTAUT.
> >
> >CRTDUPOBJ requires *OBJMGT authority to the source object.  It has been
> >that way
> >since the S/38.
> >
> >Regards,
> >Simon Coulter.
> >--------------------------------------------------------------------
> >    FlyByNight Software         AS/400 Technical Specialists
> >
> >    http://www.flybynight.com.au/
> >    Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
> >    Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
> >                                                              X
> >                  ASCII Ribbon campaign against HTML E-Mail  / \
> >--------------------------------------------------------------------
> >
> >_______________________________________________
> >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> >To post a message email: MIDRANGE-L@midrange.com
> >To subscribe, unsubscribe, or change list options,
> >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> >or email: MIDRANGE-L-request@midrange.com
> >Before posting, please take a moment to review the archives
> >at http://archive.midrange.com/midrange-l.
>
>
>
>
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> 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@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.