RE: system state program call within user state -- MI400

A nice lady posted the following question on the MC forum:

"We are wondering if there are API's that would allow us to modify the
defaults for entries we already have in our BOOTP table. We have 320
AS/400's and we're trying to roll out the new version of Netstation Manager.
These systems are still running v4r3."

When I looked into the problem, I found that configuring BOOTP is deep
within the CFGTCP menu.  You get a "command" screen for "Add BOOTP Table
Entry" that looks just like a regular command, except that it is not really
a command, and so can't be called from a command line.  You have to
interactively go through the menus to get to the entry.

So, being just clever enough to be dangerous, I decided to see what program
is being called and see if maybe I could figure out the parameters and give
the nice lady some help.  I see that I'm calling program QTODWBPO.  Okay, no
problem.  Let's call it and see what it does.

WHAMMO!

MCH6801, Object domain or hardware storage protection violation.  Seems that
QTODWBPO is a system domain program.  So I guess I'll restate the question
from a slightly higher altitude perspective: is it possible to write a
program that changes itself to system state in order to call one of these
programs, and if so, is it by definition a bad thing?

I'd like to hear some opinions on this...

Joe "CETBD" Pluta


> -----Original Message-----
> From: owner-mi400@midrange.com [mailto:owner-mi400@midrange.com]On
> Behalf Of Leif Svalgaard
> Sent: Monday, October 16, 2000 2:18 PM
> To: MI400@midrange.com
> Subject: Re: system state program call within user state
>
>
> Ray,
> Chapters 7 and 15 in my eBook (http://iSeries400.org) explain
> this in great
> detail.
> Here I have to be reasonably short (IBM manuals also explain this well,
> RTFM).
> Objects that are visible to you are either in the user domain or in the
> system domain.
> Executable objects are either in the user state or the system
> state (or can
> inherit state,
> but forget about that little detail).
>
> Briefly:  user state programs can only call other programs if
> they are in the
> user
> domain. QQUDC is in the system domain. Your RPG program can therefore not
> call QQUDC as long as it itself is a user state program. With me so far?
> you can't do it, period.
>
> Now, if you change your program to have the system state
> attribute (set the
> byte
> at offset 15C1 to x'80' instead of what it was: x'01' - using
> SST, if you are
> authorized
> to do that), then you CAN call QQUDC. Changing your program to
> system state
> may have other ramifications preventing you from calling other user state
> programs
> if you pass them parameters, so you may not wish to do this.
>
> Is it absolutely mandatory that you call QQUDC? what is it that QQUDC does
> that has business value to you?
>
> Sorry to sound so negative, but you are getting in deep if you mess with
> system state
> stuff without knowing exactly what you are doing and having a
> good reason for
> it.
>
> Leif

+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---