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

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 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].