× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Virtual Device spontaneous combustion!
  • From: pytel@xxxxxxxxxx
  • Date: Tue, 13 Apr 1999 08:40:49 -0500

It is documented in several places - in TCP/IP Configuration manual, for
example - in TELNET chapter.
What you see is WAD (Works As Designed) behaviour. System gets a request
for a particular type of device and tries to make device fit this request.
You may try to remove authority to delete virtual devices from QTCP profile
(TELNET server job is running under) - remove *OBJEXIST. In this way, when
TELNET server will try to delete device description, it will fail.

Best regards
    Alexey Pytel



John Earl <johnearl@toolnet.com> on 04/11/99 06:23:52 PM

Please respond to MIDRANGE-L@midrange.com

To:   MIDRANGE-L@midrange.com
cc:    (bcc: Alexei Pytel/Rochester/IBM)
Subject:  Re: Virtual Device spontaneous combustion!





Alexy,

Thanks for the response....

I have a question about this statement...


> What you see is the documented behaviour of QAUTOVRT. System will not
> create NEW devices to go beyond QAUTOVRT. Otherwise, system will not
delete
> virtual devices and generally will not try to decrease their number down
to
> QAUTOVRT setting.
>
I don't want the system to delete devices, I just want it to leave them
alone.
If I have a 3477 defined, and someone comes along emulating a 3197, I want
the
system to do _nothing_.  Instead it appears that it will delete an existing
device and then create a new one that will be usable by a 3197 device type.
I
should be able to control this behavior shouldn't I?

Also, can you point me to the manual where this is documented?   I havn't
located
it yet.

Thanks for your help,

jte


pytel@us.ibm.com wrote:

> QAUTOCFG relates to directly attached devices only (such as twinax
> workstations and printers, tape devices etc.)
> QAUTORMT as name suggests, apply to remote devices configuration - such
as
> workstations attached to remote control units.
> Auto create controllers setting controls only APPN operation - creating
> APPN/APPC controllers for an incoming request on a LAN.
> What you see is the documented behaviour of QAUTOVRT. System will not
> create NEW devices to go beyond QAUTOVRT. Otherwise, system will not
delete
> virtual devices and generally will not try to decrease their number down
to
> QAUTOVRT setting.
> If you want to have finer control over virtual device
allocation/creation,
> there are two mechanisms for this:
> - named device support (sessions reference pre-created devices)
> - TELNET exit program (described in TCP/IP Configuration and Reference),
> which can decide, which device can be used for a specific session.
>
> Best regards
>     Alexey Pytel
>
> John Earl <johnearl@toolnet.com> on 04/11/99 03:57:49 PM
>
> Please respond to MIDRANGE-L@midrange.com
>
> To:   "MIDRANGE-L@midrange.com" <MIDRANGE-L@midrange.com>
> cc:    (bcc: Alexei Pytel/Rochester/IBM)
> Subject:  Virtual Device spontaneous combustion!
>
> We keep getting bitten by an autoconfig type of a problem
> with our virtual devices, but I can't figure out why it's
> happening.
>
> QAUTOCFG is set to '0' (off)
> QAUTORMT is set to '0' (off) ... (but this _should_ be
> irrelevant)
> QAUTOVRT is set to 0
> And the TCPIP interface line description is set to Auto
> Creat Controllers(*NO)
>
> Yet, on whenever someone connects to an existing virtual
> device using a different device type (a 3477 for example
> trying to connect to an existing 3197 device description),
> the QTGTTELNET job will delete and recreate the device to
> suit fir the new device type.
>
> This isn't what we want to happen.  We want the system to
> keep searching for a valid device and if it doesn't find a
> match, then refuse connection.   Unfortunately, I can't seem
> to get the system to stop authomatically re-creating virtual
> devices.
>
> (OS=V4R3)
>
> Help!
>
> jte
>
> --
> John Earl   johnearl@toolnet.com
>
> PowerTech Toolworks  206-575-0711
> PowerLock Network Security www.toolnet.com
> The 400 School   www.400school.com
> --
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---



--
John Earl   johnearl@toolnet.com

PowerTech Toolworks  206-575-0711
PowerLock Network Security www.toolnet.com
The 400 School   www.400school.com
--


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.