We did that for a while too -- that's how we got close to the 450 device class limit (one device class per environment file per physical printer). Gave up on that -- too many device classes. And environment files are hard to change since they're loaded into memory the first time thety're referenced and don't go away until the box is rebooted. Now we use Unispool's $include <file> control language command and base the <file> on a forms message. And the control language procedure can be used as the header procedure for a type 2 device eliminating the copying of spool files from type 4 to whatever. Took a bit of work to get a forms message everywhere but we feel it was worth it. Nice and tidy now and works quite well. JWP ---------- From: internet!warren.med.harvard.edu!bmanocch To: internet!UTCVM.UTC.EDU!HP3000-L; Pickering; John NORBORD Subject: Re[2]: Pseudo Devices/MPE limits Date: Thursday, February 29, 1996 12:51PM We use device classes to tell the operator what type 4 Unispool device to send it to. Each type 4 device has an "environment" file associated with it which formats the report (landscape, portrait..tray, etc...). ______________________________ Reply Separator _________________________________ Subject: Re: Pseudo Devices/MPE limits Author: "Pickering; John NORBORD" <[log in to unmask]> at HMS-Internet Date: 2/29/96 12:50 PM Doug Werth answered... >You can configure cards that do not exist in the DTC and even >DTC's that aren't there. However, since NBSpool can move >reports from device classes as well as ldev numbers, my >personal preference is to create a single dummy device in >NMMGR and simply add as many device classes to the profile >in as needed. One psuedo device, one profile, less hassle. I concur. We use Unispool here with the same technique and with no problems. Nice and tidy, works well. There is a limit of somewhere around 450 device classes per system which we did come close to hitting at one time. But who needs 450 printers! John Pickering JWP Systems Inc Toronto