1 INFO-VAX	Tue, 02 Aug 2005	Volume 2005 : Issue 428       Contents: Re: Another blue screen  Another blue screen 0 Re: Creating Custom Printer Banner Page in DCPS?0 Re: Creating Custom Printer Banner Page in DCPS?0 Re: Creating Custom Printer Banner Page in DCPS?0 Re: Creating Custom Printer Banner Page in DCPS?0 Re: Creating Custom Printer Banner Page in DCPS?0 Re: Creating Custom Printer Banner Page in DCPS?0 Re: Creating Custom Printer Banner Page in DCPS?/ Re: Intel hammer another nail in Itanium coffin ) Re: Performance issue after 7.3-2 upgrade  Re: SMTP authentication   F ----------------------------------------------------------------------  % Date: Tue, 02 Aug 2005 11:04:19 +0200  From: S <soterroatyahoodotcom>  Subject: Re: Another blue screen& Message-ID: <42ef3712$1@news1.ethz.ch>   Mike Rechtman wrote:I > In the 60's there was a line from a song that went "when will they ever  > learn..."   . Those guys should read the uptime project top.  A But for most of the people, even relatively computer-literate, a  G computer is a thing that *does* crash from time to time. They are used  I to it like having rain in the autumn. Some of them know there are things  H rumored more stable, but look the sales reps say this solution *can* be E made safer with this and that and and and. Now it crashes badly only  B once a year, isn't that a huge improvement for the record? So why K migrate to unix? Or even worse, to that other platform what-was-its-name...    S    ------------------------------  % Date: Tue, 02 Aug 2005 10:37:40 +0300 4 From: Mike Rechtman <michael.rechtman.nospam@hp.com> Subject: Another blue screen& Message-ID: <42EF4CF3.68319EEE@hp.com>   From comp.risks:  
 <start quote> # Date: Sat, 30 Jul 2005 15:42:15 PDT . From: "Peter G. Neumann" <neumann@csl.sri.com>! Subject: Elbtunnel computer crash   H Germany: The crash of a PC controlling both tubes of Hamburg's ElbtunnelD traffic system caused traffic to back up for 14 kilometers on the A7 duringB the morning of 28 July 2005.  [Source: *Der Spiegel*, auf deutsch,	 thanks to  Bruce Schneier; PGN-ed] ;   http://www.spiegel.de/reise/aktuell/0,1518,367185,00.html  <end quote>   G In the 60's there was a line from a song that went "when will they ever 	 learn..."    Mike --  E --------------------------------------------------------------------- E Usual disclaimer: All opinions are mine alone, perhaps not even that. ? Mike Rechtman                            *rechtman@tzora.co.il* F Kibbutz Tzor'a.                          Voice (home): 972-2-9908337  B   "20% of a job takes 80% of the time, the rest takes another 80%"E ---------------------------------------------------------------------  -----BEGIN GEEK CODE BLOCK-----  Version: 3.1: GCM/CS d(-)pu s:+>:- a++ C++ U-- L-- W++ N++ K? w--- V+++$6 PS+ PE-- t 5? X- tv-- b+ DI+ D-- G e++ h--- r+++ y+++@ ------END GEEK CODE BLOCK------    ------------------------------  % Date: Mon, 01 Aug 2005 20:04:10 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 9 Subject: Re: Creating Custom Printer Banner Page in DCPS? , Message-ID: <42EEB878.2DA3913B@teksavvy.com>   Paul Anderson wrote:I > The code is "packed" at build time.  Even though not "packing" it would I > probably not cause a performance problem, the thinking through the ages I > was to make it hard for people to customize (mess up) their flag pages.   ( Yeah, making life hard for customers...   2 > Are you suggesting a PostScript dictionary here?  L yeah. create some PS dictionary with all the various job variables in there,H this way, it could be used by other modules and the user postscript codeS without really jeoperdizing code that doesn't make specific use of that dictionary.   H > What purpose would these new logical names serve?  Would it be helpful > in debugging problems?  K Knowing that a "Declaser 5100" is attached to a queue would help. Actually, M knowing that a postscript printer is attached to a queue woudl help. Consider K also your future plans to support PPDs, and providing application access to L what is attached to a queue would help applications generate postscript with= the right commands to drive that printer's special features.    I I realise that there are no plans in the roadmap for continued support of M Motif, but if it is just an omission in text, providing better integration of J DCPS and the VMS print widget would really add value. The application/userN could then be presented with a list of supported formats for that print queue,I and if you choose postcript, be given an extra window with that printer's  specific PPD derived options.    ------------------------------  % Date: Mon, 01 Aug 2005 20:27:01 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 9 Subject: Re: Creating Custom Printer Banner Page in DCPS? , Message-ID: <42EEBDD1.CA327B1F@teksavvy.com>   Paul Anderson wrote:G > I understand your need to eliminate certain items from the flag page, A > but please explain what you mean by "consistent parameters" and  > "properly indexed".   K The way I had read the original post, I understood it to mean that the user N wants more control over the what data the symbiont feeds the postscript code.   L And this goes back to my dictionary suggestion. If the symbiont sent ps codeM to create a dictionry contaning a chockful of paramenters (such as username , N node, etc etc etc), then the user could make use of any/all of those variables to fit their needs.    ------------------------------  % Date: Mon, 01 Aug 2005 21:57:24 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 9 Subject: Re: Creating Custom Printer Banner Page in DCPS? 0 Message-ID: <11etki02m81are2@corp.supernews.com>   JF Mezei wrote:  > Paul Anderson wrote: > G >>I understand your need to eliminate certain items from the flag page, A >>but please explain what you mean by "consistent parameters" and  >>"properly indexed".  >  > M > The way I had read the original post, I understood it to mean that the user P > wants more control over the what data the symbiont feeds the postscript code.  > N > And this goes back to my dictionary suggestion. If the symbiont sent ps codeO > to create a dictionry contaning a chockful of paramenters (such as username , P > node, etc etc etc), then the user could make use of any/all of those variables > to fit their needs.   > Maybe some symantics here but I wouldn't call it a dictionary.  E What I'd look into would be a utility to allow custom design (within  F reasonable limits, this isn't a work of art) of the flag/burst pages, I with some parts being static, and some possibly coming through the queue   parameters.   K Opps!  Now we're into the queue system.  It can get bloated rather quickly.   F Maybe mostly static, with tokens for some of the information, such as F username.  If the token is in the custom design, then replace it with G the appropriate data.  If it's NOT in the custom design, then the OP's  I primary objective is obtained, omitting certain data from the flag/burst   pages.  E You could also get as simple as an installation configuration script  E which asks, for each piece of data normally on the page, if the data  = should appear on the page, Yes or No.  Similar to the TCP/IP   configuration, and others.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 01 Aug 2005 22:37:43 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 9 Subject: Re: Creating Custom Printer Banner Page in DCPS? , Message-ID: <42EEDC6A.53721EC5@teksavvy.com>   Dave Froble wrote:@ > Maybe some symantics here but I wouldn't call it a dictionary.  K A dictionary is a Postscript construct that lets you store a whole bunch of J data/variables.  You can make the dictionary available or hide it from the postscript code.  I So DCPS could build a dictionary full of the job specific data, use those J variables to build the flag page, then close the dictionary to prevent anyH conflict with the postscript program. But that program could re-open the4 dictionary and access the variables if it wanted to.  M > Opps!  Now we're into the queue system.  It can get bloated rather quickly.   L No. The DCPS symbiont is attached to the queue system. It just needs to sendL the propor postscript commands to (for instance) build that dictionary, thenM open the relvant DCLP library module and transmit its contents to the printer ) followed by your actual postscript files.   F > You could also get as simple as an installation configuration scriptF > which asks, for each piece of data normally on the page, if the data> > should appear on the page, Yes or No.  Similar to the TCP/IP > configuration, and others.  M Not necessary. DCPS can simply build a dictionary with ALL of the data it has L available, and let the postcript code that builds the flag page use whatever variables irt wants to use.    ------------------------------  $ Date: Mon, 1 Aug 2005 21:50:27 -0500? From: "Christopher Story" <ke6rwj@spam-eater-remove-me-msn.com> 9 Subject: Re: Creating Custom Printer Banner Page in DCPS? ( Message-ID: <z9BHe.128$qv2.127@fe07.lga>  7 "Paul Anderson" <paul.anderson@hp.com> wrote in message / news:010820051544499155%paul.anderson@hp.com... 8 > In article <FEtHe.6$c45.0@fe05.lga>, Christopher Story. > <ke6rwj@spam-eater-remove-me-msn.com> wrote: > L > > Is there any method to manipulate the sections below.  or is this in the > > symbiont only? > >  > > (TAZ::AAGAARD) username  > > (JOB 39) jobid > > (DCPS$IVP_POST) name) > > (Hewlett-Packard Company) companyname % > > (OpenVMS Alpha V7.3-2  ) systemid  > > (DCPS F2.5) symbiontid > F > I wouldn't think you'd really want to modify most of these, with theB > exception of "companyname".  You're suggesting there be a way to, > eliminate the other items entirely, right? > ) > > I would need to add this PS variable:  > >  > > mark8 > >  (TAZ::AAGAARD) (DCPS$IVP_POST) {setjobinfo} stopped > > cleartomark  >  > What would this do?   K This variable supplies the imaging software with the job title and username @ of the person who spooled it.  So it can be placed in the properK repository.(or directory structure, so the user can go see his/her jobs and  the titles)    > E > > I'm not expecting this to be fully supported, we are moving to an I > > imaging system for all output, and we need to provide the system some > > > consistent parameters so the jobs can be properly indexed. > G > I understand your need to eliminate certain items from the flag page, A > but please explain what you mean by "consistent parameters" and  > "properly indexed".   G The software is looking for the same parameters in the job from all the K systems that spool to it.  It basically scans the job as it receives it and @ looks for the PJL's or grabs the setjobinfo variable from the PSL interpreter.  It then places this in a DB table that links it to a web basedD viewer that allows users to grab the jobs that are spooled for them.H Without this info the jobs from DCPS are spooled to a "common" area thatL requires human intervention to place them in the proper area. (so they don't use it)   H > > The other option is to add PJL commands to the LPS$$ppp_INITPSDEVICE V2.5-1, < > > but I dont see a way to get the variables to the module. > >  > > [ESC]%-12345X@PJL ! > > @PJL JOB NAME="DCPS$IVP_POST" $ > > @PJL SET USERNAME="TAZ::AAGAARD"" > > @PJL ENTER LANGUAGE=POSTSCRIPT > > %!PS-AdobeE > > %  Copyright 1988-2004 Hewlett-Packard Development Company, L.P. " > > % LPS$$ppp_INITPSDEVICE V2.5-1 > G > DCPS ignores PJL commands.  Sometimes, items like Username are put in E > the file as PostScript comments.  DCPS does not generate these, but H > since some printers use this information, we've thought of adding suchG > comments at the beginning of the file.  Not all information about the @ > job is available at that time, however, so it could never be a7 > substitute mechanism for passing all flag page items.   K Exactly my point..  The usernames are not available at the time the INIT is E sent so the comments cannot be added at the beginning, but using a PS J variable "(TAZ::AAGAARD) (DCPS$IVP_POST) {setjobinfo} stopped"  they could8 be available anywhere after the username for PS to grab.  J Many printers also use the same type of variables to add the print jobs to internal "printed jobs" lists.  H adding the variable during the creation of the "(TAZ::AAGAARD) username"D text would allow this to work.  If it is at all possible to edit theE generation on the flag page where the varables are passed in would be 
 excellent.  H I appreciate your responses, I know this is outside of the design of the
 system....   Chris    ------------------------------  $ Date: Mon, 1 Aug 2005 21:53:35 -0500? From: "Christopher Story" <ke6rwj@spam-eater-remove-me-msn.com> 9 Subject: Re: Creating Custom Printer Banner Page in DCPS? ( Message-ID: <vcBHe.129$qv2.119@fe07.lga>  : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:42EEDC6A.53721EC5@teksavvy.com... > Dave Froble wrote:B > > Maybe some symantics here but I wouldn't call it a dictionary. > J > A dictionary is a Postscript construct that lets you store a whole bunch ofL > data/variables.  You can make the dictionary available or hide it from the > postscript code. > K > So DCPS could build a dictionary full of the job specific data, use those L > variables to build the flag page, then close the dictionary to prevent anyJ > conflict with the postscript program. But that program could re-open the6 > dictionary and access the variables if it wanted to. > F > > Opps!  Now we're into the queue system.  It can get bloated rather quickly. > I > No. The DCPS symbiont is attached to the queue system. It just needs to  sendI > the propor postscript commands to (for instance) build that dictionary,  thenG > open the relvant DCLP library module and transmit its contents to the  printer + > followed by your actual postscript files.  > H > > You could also get as simple as an installation configuration scriptH > > which asks, for each piece of data normally on the page, if the data@ > > should appear on the page, Yes or No.  Similar to the TCP/IP > > configuration, and others. > K > Not necessary. DCPS can simply build a dictionary with ALL of the data it  has E > available, and let the postcript code that builds the flag page use  whatever > variables irt wants to use.     J The dictionary would be the most efficient and flexible way to do it.  TheF code required would be minimal and the modules would have access to it* through the PS interpreter on the printer.  F It would lead to an endless amount of site specfic customizations with' modules!!!!  A truly useful toolkit....    Chris    ------------------------------  % Date: Tue, 02 Aug 2005 02:58:22 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 9 Subject: Re: Creating Custom Printer Banner Page in DCPS? 0 Message-ID: <11eu66ced9k6j6c@corp.supernews.com>   JF Mezei wrote:  > Dave Froble wrote: > @ >>Maybe some symantics here but I wouldn't call it a dictionary. >  > M > A dictionary is a Postscript construct that lets you store a whole bunch of L > data/variables.  You can make the dictionary available or hide it from the > postscript code. > K > So DCPS could build a dictionary full of the job specific data, use those L > variables to build the flag page, then close the dictionary to prevent anyJ > conflict with the postscript program. But that program could re-open the6 > dictionary and access the variables if it wanted to. >  > M >>Opps!  Now we're into the queue system.  It can get bloated rather quickly.  >  > N > No. The DCPS symbiont is attached to the queue system. It just needs to sendN > the propor postscript commands to (for instance) build that dictionary, thenO > open the relvant DCLP library module and transmit its contents to the printer + > followed by your actual postscript files.  >  > F >>You could also get as simple as an installation configuration scriptF >>which asks, for each piece of data normally on the page, if the data> >>should appear on the page, Yes or No.  Similar to the TCP/IP >>configuration, and others. >  > O > Not necessary. DCPS can simply build a dictionary with ALL of the data it has N > available, and let the postcript code that builds the flag page use whatever > variables irt wants to use.   I Well, I was thinking of something really simple, that wouldn't even need  G DCPS.  That was where this started, but things might be more useful if  H it helped all VMS users, including those not using DCPS.  Don't know if  that exists anymore.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   Date: 2 Aug 2005 15:58:38 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)8 Subject: Re: Intel hammer another nail in Itanium coffin, Message-ID: <3l9jheF11ld30U1@individual.net>  0 In article <11ev48vr6olc28f@corp.supernews.com>,* 	Dave Froble <davef@tsoft-inc.com> writes: > Alan Greig wrote: G >> According to the Intel slides published on the The Inquirer website  E >> Intel are now targetting the Itanium only at market segment "RISC  K >> replacement (2/4/8+sockets)". The market segment "Enterprise and volume  D >> (4/8+ sockets)" is now targetted by the 64 bit Intel Xeon MP and G >> successors. The roadmap shows that Intel have no remaining residual  9 >> plans to force Itanic into the wider Enterprise space.  >>  C >> See the slides at http://www.theinquirer.net/?article=25073. In  : >> particular the Intel Enterprise Server Platform Roadmap > D > Are there still any who doubt what AMD could/did do to the itanic? > F > Come on, you know who you are, the ones that loudly proclaimed that J > Hammer would never make it, that Intel had too much money, etc.  Any of M > you want to comment on how things developed?  Too busy licking your wounds?  >   H So Dave, come on.  Don't hold back.  Tell us what you really think.  :-)   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 2 Aug 2005 05:01:28 -0700 + From: "Jeff Anicker" <anickerj@comcast.net> 2 Subject: Re: Performance issue after 7.3-2 upgradeC Message-ID: <1122984088.248285.247890@g14g2000cwa.googlegroups.com>   D Good news.  HP engineering has discovered a problem with xfc when itF hits it's minimum size.  We have a lot of files open when it hits thisF minimum level and some memory is tied to these open files and can't beC released, but xfc keeps trying.  Until the patch is available it is E suggested to set vcc_max_cache equal to the amount of memory reserved + for xfc or get more memory.  I may do both.    Thanks to all for your input.    Jeff   ------------------------------  * Date: Tue, 2 Aug 2005 10:15:37 +0000 (UTC) From: david20@alpha2.mdx.ac.uk  Subject: Re: SMTP authentication) Message-ID: <dcnh49$sjr$1@news.mdx.ac.uk>   _ In article <1122926109.453187.265600@g44g2000cwa.googlegroups.com>, bob@instantwhip.com writes: 4 >it is possible to do it with PMDF or TCPware. It is" >the best IP stack for OpenVMS ... > - PMDF definitely supports SMTP AUTH with SASL.   
 David Webb Security team leader CCSS Middlesex University   ------------------------------   End of INFO-VAX 2005.428 ************************