Conference 44.370::system_management

    Backups and Upgrade information ...
    
    SBPEXE will shut down for a full backup of its system
    disk very early on Friday morning (May 10th). The system
    should be available again by 8:00 am.
    
    The latest DECwindows V3 Field Test software will be installed
    on Tuesday evening, May 14th. All satellites will be shut down at
    5:30 pm for this. They should all be available for 9:00 am
    on Wednesday.
    				Peter Russell, x 2464.
    

    
    Backup information...
    
    Due to a cable problem I.S. were unable to complete backups of the
    system disk on SBPEXE.  I rebooted the machine this morning at 8:30,
    that is why most of the workstations were not working this morning.
    
    The backups will be done tonight instead at 17:30 tonight by I.S.
    
    Chris.

    SBPEXE hung this morning, due to a fault in the ethernet cable.
    This was replaced within a very few minutes, and EXE continued.
    Unfortunately, the satellites all died, and re-booted.
    
    For some reason, the start up wasn't clean on all of them, and we
    are working our way around getting them up properly.
    
    Peter.
    

    Decwindows V3.0 EFT 2 has been successfully installed on SBPEXE.
    
    Chris will be looking at AUTOGEN information during the day, and
    it may be necesary to bounce either EXE or the satellites.
    
    There are some minor differences to the presentation with this release;
    Chris can point you in the direction of documentation if you wanna
    read it, but he's on his own on Wednesday, so please bear with him if
    he's a bit pushed.
    
    We will make bookreader versions available in the next day or so.
    
    Peter.
    
    (Oh and by the way, this version seems to be faster than the previous
    one - I'm sure you will feedback your thoughts on this!! We have made a
    change to ethernet routing, which may also help.)
    
    
    

	I am currently testing out a tool that limits the block size of
	jobs on the LPS printers during the day.

	This tool switches the BLOCK_LIMIT=500 on at 8 am and switches it
	off at 6 pm.

	If your job exceeds the block size of 500 during these hours, it 
	will be put on hold until the restriction is lifted. If this is the
	case you will receive the following message :- 

   pending status caused by job size above queues maximum job size limit

	This is only installed on the SBPEXE cluster at the moment, while 
	it proves to me and others that it works.

    I guess that this will cause problems.
    
    The main problem is that with Postscript it is impossible to tell how
    many pages of output are produced from simply the block size.
    
    A screen dump or graphicaly intensive file could *easily* be 50-100 blocks
    per page! Whereas a cleverly compressed piece of PS could be 1 block =
    10 pages (or more).
    
    Also don't forget to take into account things like /Param=(Sides=2,num=2).
    I always use these and they cut down printout size by a factor of 4.
    Many people don't even know these options exist (Or that a LPS20 is a
    double sided printer !)
    
    If you really want to go ahead with these options then the only way to
    accuratly do it is as follows.
    
    Put a UIC on LPS$* disabling normal user access.
    
    Define a symbol
    
    	$ LPSprint filespec queue sides number-up
    
    This symbol copies the files into a SYSTEM directory.
    
    Have a special batch job which scans this directory for files every 
    minuet. The job the searches the .PS files for ``%%Pages: xx'' to
    determine how may pages the files has.
    
    If xx / sides / number-per-size > 20 (or whatever) then queue
    /after=6pm otherwise queue immediatly.

This tool doesn't affect any of the parameters, they are determined by the
LPS* logicals.

The BLOCK_LIMIT does not prevent a job being queued, it just puts it on hold
unit the BLOCK_LIMIT is turned off.

I am not really bothered about relatively small jobs, whether cleverly 
compressed or not. It is the printing of very large documents during the day.

There is nothing to say that the BLOCK_LIMIT cannot be overridden by the 
system managers, but this would have to be heavily justified.

This BLOCK_LIMIT is on the main LPS queues, not on the generic queues, so
searching for ``%%Pages: xx'' wouldn't really help on non-PS jobs.

The BLOCK_LIMIT may be increased/decreased if normal usage over a period of
time, proves this limit to be inappropriate.

	I think Rik has made a good point, however I'm concerned that the
	directory would be scanned every minuet ! How can we be sure that
	the printer would know when a minuet had been played ?

	But seriously, the block size is a good way of delaying the
	constant printing of manuals on the PS printers !

	Wob

>>    Have a special batch job which scans this directory for files every 
>>    minuet. The job the searches the .PS files for ``%%Pages: xx'' to
>>    determine how may pages the files has.

    
    Quel (sp!) Surprise, SBPEXE has died yet again - Can I be booted off
    Futurs ?
    
    Rob

	1. I had an LA75 queue on SOOTY so that I could pribt stuff from JENNY.
	Any chance of setting one up on SBPEXE (JENNY_LA75) which will start
	each time the machine boots ?

	2. Also I can't find some Bookreader books: ADG documentation and
	standarda e.g. I.S. Acceptance Criteria or the VMS DCL Dictionary and
	others. DECW$BOOK on JENNY looks like:

	(LNM$SYSTEM_TABLE)

	  "DECW$BOOK" = "SYS$COMMON:[DECW$BOOK]"
  	      = "DISK$BOOKLIB:[000000]"
 	      = "CUCKOO::CUCKOO$DUD255:[DECW$BOOK]"

	(DECW$LOGICAL_NAMES)

	  "DECW$BOOK" = "SYS$SYSROOT:[DECW$BOOK]"

	Is this correct, and if so could the books be added, found etc...

>	1. I had an LA75 queue on SOOTY so that I could pribt stuff from JENNY.
>	Any chance of setting one up on SBPEXE (JENNY_LA75) which will start
>	each time the machine boots ?

JENNY_LA75 is there, but it should be  "on JENNY::TTA3" not on SBPEXE::

>	2. Also I can't find some Bookreader books: ADG documentation and
>	standarda e.g. I.S. Acceptance Criteria or the VMS DCL Dictionary and
>	others. DECW$BOOK on JENNY looks like:


ADG documentation (standards etc) is under Library 2

VMS DCL dic. is under Library 3

Book logical is correct.

Re a few back;

as Jane said, the intent is not to prevent yopu printing large documents,
at this stage it is to prevent the "blocking up" of the LPS's by large
prints.

In many cases, the manual or whatever is not needed in hard copy format.

Although printing duplex and number_up does save paper, it doesn't save time.

If people continue to print large, unnecessary documents, maybe we will need
to review just how we make use of these printers.

Peter.

Recently I found a small program that takes as input a Postscript file, and
returns as output a file containing the TEXT from the postscript.

I find in invaluable to read postscript documents, and even cut to a 
text editor, without having to print the postscript, and retype it.


If anyone would like a copy of the program, Please contact me.


David

    I have one that takes bookreader and produces text ...

Wow!! That sounds extremely Useful.. C'n I have a copy???



David

Thanks.

Shouldn't we all put these in a TOOLBOX somewhere??


David

    There is a new version of DDE available, X1.1.
    
    I'll pull it over, and do some playing with it.
    
    If it looks OK, I'll install on SBPEXE around the middle of next week.
    
    Peter.
    

I've installed the latest DDE X1.1 on SBPEXE, and it seems to work fine.

If it comes up with a tiny window, resize it to the correct size, and
then use Customize to save the attributes.

Peter.

    
    Tonight (27-June) I'm going to install the latest version of
    DECWindows, the EFT3 (external field test) kit.  If there are any
    problems then please call me on x2658.
    
    Please leave all machines at the login prompt.
    
    Chris.

    
    The windows installation went OK, and you all thought you were safe for
    a bit...'twas not to be -
    
    
    Last night, the engineers decided to shut down the air-conditioning,
    SBPEXE was frying so it shut itself down.  We didn't know about this
    until this morning.  So, that's the reason it was down.  If there are
    any problems contact myself or Darran.
    
    Chris.

    
                     ********************************
                     * SCHEDULED SHUTDOWN OF SBPEXE *
                     ********************************
    
    
    SBPEXE will be shut down (NOTE: ALONG WITH *ALL* THE WORKSTATIONS
    
              BOOTED FROM IT) on Tueday 16th July at 17:30.
    
    
                       This is for routine maintenance.
    
    
    
    Chris. x2658