On 16-Mar-2012 12:48 , Paul Therrien wrote:
This may be so, but I would have agreed with Jerry that setting
QAUTOVRT to 0 would prevent the automatic configuration of virtual
devices.
I see Jerry already discovered this, so for the archives.... not that
many people [other than Jerry] will still find the v5r1 information all
that relevant.
To prevent the automatic creation, after changing QAUTOVRT=0, any
existing devices under\associated with the Virtual WorkStation *VWS
controllers with naming QPACTL## must be made unavailable to device
selection. Deleting the device descriptions using DLTDEVD [after VRYCFG
*DEV *OFF] *before* the device selection for an unnamed device was
attempted would prevent any new devices being created; obviously none
available for selection. After that, the requests would fail to start
due to an inability both to select and create a device [CPF8940 I
believe], because there are no additional devices available for
selection beyond the value allowed by QAUTOVRT; i.e. a situation for
which a new device would actually need to be created, to satisfy the
device selection request. Some other actions that may serve to
similarly limit the ability of the device selection for any remaining
devices:
- authorization revoked from user QTCPIP to the remaining *VRTDSP
configuration objects of type *DEVD attribute DSPVRT on QPACTL##?
- ensure the device is already in use when device selection runs;
impractical in a general sense, but likely sufficient for testing.
- vary off the devices? I doubt this works, as I believe device
selection effects varyon as needed [just as dlt\re-crt or chgdevd to
match type and model] except when the device had been varied off per
"disabled" due to invalid signon attempts.
_i Managing virtual devices i_
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm?info/rzal3/rzal3managevd.htm
"... you must manually delete any virtual devices that exceed the
QAUTOVRT limit. If you delete devices to enforce a smaller QAUTOVRT
value, begin by deleting the devices from the controller with the
highest QPACTLnn value. ..."
Shannon ODonnell on Friday, March 16, 2012 2:43 PM wrote:
You need a Telnet Exit Program.
Had the emulator used [the feature to provide] a named device, then I
am unsure what could be done to prevent the autocreation of the named
device, other than either ending the *TELNET service for that type of
access or to use the Exit Point Name: QIBM_QTG_DEVTERM Format Name:
TERM0100 to control "Telnet device initialization" with an exit program.
That is because, although a named device could have been
"automatically created", the named devices are not tracked to the
QAUTOVRT device count\limit because the named devices are created on the
*VWS controllers with naming QVIRCD#### instead of the naming QPACTL##.
For that reason, the above response by Shannon may still be valuable,
beyond only removing the extra [beyond QAUTOVRT] automatically created
devices to prevent unnamed device selection\access by a telnet client.
Note: The DSPDEVD does not present a "created by auto-configuration"
and the documentation often alludes to "automatically created devices"
as though they are specially tracked, and known to be different than
"user created devices". I infer, though I do not know, that the naming
QPADEVnnnn is what determines the difference. If a user-created device
is created on the QPACTL## VWS controller, I am not clear if the
auto-vrt configuration will choose to delete and recreate or modify the
device as auto-config deems necessary, or if the device is left
unmolested by auto-config even if using naming QPADEVnnnn.?
_i Planning for the Telnet server i_
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm?info/rzaiw/rzaiwtelsetup.htm
_i Automatically configuring virtual devices with Telnet i_
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm?info/rzaiw/rzaiwautcfgdev.htm
"...
If the devices already exist on the virtual controller, the Telnet
server can use them. Telnet server will modify the attributes of an
existing device to match the client request if that virtual device is
requested by name.
... system value [QAUTOVRT] does not affect devices attached to the
QVIRCDnnnn controllers, because these are not default system devices.
Typically, QPADEVnnnn devices are attached to QPACTLnn controllers while
named devices, such as NEWYORK001, are attached to the QVIRCDnnnn
controller.
... Only virtual devices that are attached to QPACTL nn count toward the
[QAUTOVRT] Devices System Values - Maximum number of devices.
...
"
Jerry C. Adams on Friday, March 16, 2012 2:29 PM wrote:
I have system value<<SNIP>> QAUTOVRT = 0
Which, I thought, would prevent a telnet service, such as iSeries
Access or Telnet from a DOS command line, from gaining access to
a System i. That is, no signon panel, no login.
Obviously, that's not true (we're on V5R1). I was just working
with a purchasing guy. He already had iSeries Access installed
but no PC5250 session configured. So, without thinking, I
started the Create New Session.
My immediate thought was, as I intimated earlier, "This is going
to blow up." But it didn't. I got one of those generic
QPADEVxxxx sessions.
I, also, got the QPADEVxxxx signon when I ran Telnet from a DOS
command box.
Is there any system value or whatever that would prevent access
to a signon panel?
If the system had reached v5r2, then the QIBM_QPA_DEVSEL Device
Selection Exit Program would provide some capability; registered via the
Registration Facility and activated by QAUTOVRT=*REGFAC instead of using
a number:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzakz/rzakzqautovrt.htm
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/apis/xpgmdevs.htm
Regards, Chuck
midrange.com
