Re: Virtual Device spontaneous combustion - Resolution!

If any of you paid attention to this thread, the folks at IBM have provided a 
fix to this
problem.

The problem was that Device Descriptions that were secured by Authorization 
Lists would
'forget' what Authorization List they were secured by when Telnet (and probably 
any other
process) deleted and recreated them in place.  The V4R3 PTF SF56770 has fixed 
the problem
nicely.  (The V4R2 PTF IS SF56835).

Thanks to Jeffery and the others that worked this out.

jte


John Earl wrote:

> 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
> +---



--
John Earl                                              johnearl@toolnet.com
PowerTech Toolworks                         206-575-0711
PowerLock Network Security              www.400security.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
+---