Re: Virtual Device spontaneous combustion!

Jeffrey,

Jeffrey Stevens wrote:

> John,
>
> I'm guessing Telnet clients are requesting these devices being used by
> your APPC clients.  If you set up named devices for APPC, and then a
> client Telnet comes asking for that device, it is possible the authorities
> established under the SNA session might vanish.

Actually no, we're not using APPC at all for the PC connections.  All of the 
connections
are Telnet, it's just that everyone is using a different package, so the 
terrminal types
differ.

But I just discovered something else that is odd about these delete/recreate.

My problem is that all of the devices are secured by Authorization list DEVD.   
When
device QPADEV0003 get's deleted and recreated (for example), the new device 
lists
*PUBLIC's authority as *AUTL (that's good), but the new device description 
object  has no
Authorization List attached to it.  (???!!!???)    Shouldn't the DLT/CRT 
procedure
duplicate this as well?    If it did, I wouldn't have an authority problem and 
wouldn't
care if Telnet was deleting and recreating my devices.   But the way things are 
working
now, if UserA causes a device to be deleted and recreated, USERA is not 
authorized to use
the device because *PUBLIC's authority is controlled by an Authorization list 
that is not
attached to the object.

Is this the way it's supposed to work?

(hope not)

jte




>
>
> You've probably come to expect non-QPADEVnnnn (meaning APPC) devices to be
> left alone by the system.  However, TN5250E now gives you the ability to
> select device names, and the system extends its "delete/recreate" support
> to these objects, just like it does for QPADEVnnnn.  So, if a named device
> was created for APPC, and then later a client TN5250E came in asking for
> that same named device (and it was not already "in use"), it could get
> deleted/recreated to satisfy the terminal-type request for client
> Telnet.
>
> It's perfectly acceptable to use Telnet User Exits to force Telnet clients
> to use QPADEVnnnn (or any other root name) named devices.  By forcing
> Telnet clients to a class of names, you can avoid conflicts with legacy
> APPC support and allow both SNA and TCP to co-exist.
>
> > Date: Tue, 13 Apr 1999 12:57:58 -0700
> > From: John Earl <johnearl@toolnet.com>
> > Subject: Re: Virtual Device spontaneous combustion!
> >
> > Jeffrey,
> >
> > Actually, no.  My problem stems from the fact that I have authorities (and 
>an
> > authority list) set on the device, and when the device gets deleted and 
>recreated,
> > all my authorities go away.   This makes for the interesting situation 
>where someone
> > can connect to the /400, delete an existing device description and then 
>create a new
> > device that they are not authorized to use because the authority list is no 
>longer
> > attached to the object.
> >
> > I'm not crazy about having Telnet delete and recreate device descriptions, 
>but if
> > other considerations make that necessary could the authority lists be 
>preserved?
> > When a program  is re-compiled all of the old program's authorities are 
>kept in
> > place...  couldn't device descriptions behave the same way?
> >
> > - --
> > John Earl   johnearl@toolnet.com
> >
> > PowerTech Toolworks  206-575-0711
> > PowerLock Network Security www.toolnet.com
> > The 400 School   www.400school.com
>
> --
> J.S. (Jeffrey) Stevens  AS/400 TCP/IP (Telnet/WSG/LPD)
> +---
> | 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
+---