1 INFO-VAX	Sat, 01 Jul 2006	Volume 2006 : Issue 363       Contents:> Re: Education Ministry rethinks payroll plans (Oracle and VMS) Re: Floating point questions' Making LIB$*_VM_PAGE Caller's-mode safe + Re: Making LIB$*_VM_PAGE Caller's-mode safe G Re: zipping large files (was Re: Info-ZIP's Zip V2.32 is now available) G Re: zipping large files (was Re: Info-ZIP's Zip V2.32 is now available)   F ----------------------------------------------------------------------   Date: 1 Jul 2006 06:00:49 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) G Subject: Re: Education Ministry rethinks payroll plans (Oracle and VMS) 3 Message-ID: <ipvFeJcQsI0W@eisner.encompasserve.org>   _ In article <1151728170.753344.258910@j8g2000cwa.googlegroups.com>, dooleys@snowy.net.au writes:    > So the consensus seems to be- > "don't run payroll systems - it's too hard"   F I don't think _anyone_ said that.  The problem with payroll systems is3 that the incentive for insider attacks is too hard.   3 > "don't provide employees with payslip information $ > over the internet - it's too hard"  C Nobody said that either.  A daily transfer by removable media to an ) Internet system could be quite effective.   B > Millions of employees get paid via Windows or Linux/unix systems6 > and can also check their payslips over the internet.  - Millions of people run Windows on their desk. $ Millions of people smoke cigarettes.! Many people engage in sky-diving. 6 That is not a basis for recommending these activities.   ------------------------------  % Date: Sat, 01 Jul 2006 13:44:38 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> % Subject: Re: Floating point questions ; Message-ID: <66931$44a66027$50db5015$16638@news.hispeed.ch>    Jeff Campbell wrote: > Dave Froble wrote: >> JF Mezei wrote: >>> Dave Froble wrote:L >>>> I'm thinking it's probably interesting how you get stuff to work in any >>>> base other than 2.  >>> & >>> Cobol does it with packed decimal. >>I >> Uh... yeah... but, I've never seen a 'packed decimal' CPU.  Every one  I >> I've seen uses only ones and zeros.  Yeah, binary, that's what that's  
 >> called. >>F > Sure you have! 8-)  VAX (or PDP-11) with the CIS... ADDP, SUBP, etc. >   I PDP-11s with the CIS (Commercial Instruction Set) module could do string   integer arithmetic too.    ------------------------------  $ Date: Sat, 1 Jul 2006 21:00:56 +08003 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 0 Subject: Making LIB$*_VM_PAGE Caller's-mode safe1 Message-ID: <e85rie$5tu$1@news-02.connect.com.au>    Hi,   H Yes, it's that paragon of the futile again. Today's installment "How I'dL change LIB$*_VM_PAGE to support being called from inner-modes". For those ofL you with the source listings, please turn to psalm LIBVMPAGE.LIS around line 1199: -   G I would link LIBRTL.EXE against SECURESHRP.EXE and then export a Global D (COMMON) Psect from there called _LIB$VM_COMMON via the SECURESHRP's@ Symbol_Table. Living in a PROTECTed image, this Psect would haveH User/Supervisor Read and Exec/Kernel write access. The Psects would then look like this: -    .Psect _lib$vm_common   
 Krnl_zone: .long 0, 0 ; Queue Header  .long 0, 0, 0 ; Counters
 Exec_zone: .long 0, 0 ; Queue Header  .long 0, 0, 0 ; Counters   .Psect _lib$data Super_zone:  .long 0, 0 ; Queue Header  .long 0, 0, 0 ; Counters
 User_zone: .long 0, 0 ; Queue Header  .long 0, 0, 0 ; Counters  B I would then obtain the CURR processor mode via MOVPSL and use theK appropriate pool for the mode we're in. That is MOVAB xxxx_ZONE,R4. If some I hacker tricks the code into thinking it is in Exec-Mode, when it tries to L write to lib$vm_common an  ACCVIO will be triggered. I didn't spend a lot ofJ time at it, but after a quick glance at the code it seemed that as long asE the correct memory queue had been identified then the rest was pretty J transparent? (Oh, you'd obviously have to remove the hard-coded psl$c_userE on the $expreg call so that each mode allocated pages it owned to its L specific queue.) The strategy is simply to move all the "OWN" storage into a protected psect where needed.   H OK, Exec can mess with Kernel and User can stomp on Supervisor. AnythingF else? (Leaving lib$*_vm to one side for the moment and hoping that theK correct layering of the calls may isolate the change. "Default_Zone" has to  go into common etc)   J The downside as I see it, is that I suspect that there are many and variedI lib$*vm_page callers that absolutely rely on sharing a *single* heap pool J across processor modes. (As you know, I for one, would like to allocate atF Exec and Free at User. An extra "mode" parameter can be later added toK lib$get_vm*, so that you can allocate from a lower mode's heap.) So despite F Hoffs well-intentioned sabre-rattling, I see VMS engineering being tooH pragmatic to break a (substantial?) amount of existing code. Unless. . .  L Like the hypersort RTL, could lib$*vm* call out to a second VM_HEAP RTL thatJ defaults to the current behaviour but if defined, it would point to a UWSSI RTL that would interrogate PREV_MOD to decide what heap to allocate from?   H Why not treat it as an quasi-open-source excersise? Let's keep coming upE with solvable problems until there are none left. Ok, it's your turn.    Regards Richard Maher   8 PS. "Four Stacks - Four Heaps" - Gotta like the symmetry   ------------------------------   Date: 1 Jul 2006 07:13:40 -0700   From: "Ian Miller" <ijm@uk2.net>4 Subject: Re: Making LIB$*_VM_PAGE Caller's-mode safeC Message-ID: <1151763220.859000.112320@m79g2000cwm.googlegroups.com>   F I think the idea of having four heaps for four modes and the alternate7 UWSS form of the lib$vm routines appears to be good to.   D Of course there is nothing stopping you from writing your own memoryF allocation routines as a UWSS and calling from your own code but there* is a case for these routines to be in VMS.  G I wonder if the overhead of calling a memory allocation routine that is < a system service rather than a mode-of-caller rtl routine is significant.  G In your proposed scheme, being able to mess up the supervisor mode heap  seems a bad thing.   ------------------------------  % Date: Sat, 01 Jul 2006 06:46:19 -0700 # From: "Tom Linden" <tom@kednos.com> P Subject: Re: zipping large files (was Re: Info-ZIP's Zip V2.32 is now available)) Message-ID: <op.tb0i7hj9zgicya@hyrrokkin>   F On Fri, 30 Jun 2006 09:13:25 -0700, Tom Linden <tom@kednos.com> wrote:  5 > On Thu, 29 Jun 2006 11:28:41 -0700, Hoff Hoffman  =   " > <hoff-remove-this@hp.com> wrote: >  >> Tom Linden wrote: >>I >>> Do you have it for Alpha as well?  If so, could you post it somewher=  e  =   >>> please?  >>G >>    gzip 1.3.3 and likely 1.3.5-1 (if not later) will be generally  =   I >> available on the Freeware V8.0 distribution.  (Tom now has a copy of =  an  =   I >> OpenVMS Alpha gzip port to look at; he probably didn't realize it, bu=  t  =  6 >> he just volunteered to test a gzip port for me. :-) >>& >>> How is it an improvement on 1.2.4? >>I >>    Other than the large-file support that I centrally needed as part =  of  =   I >> compressing the OpenVMS I64 DVD kits, I didn't particularly investiga=  te  =   7 >> the details of the changes made to gzip after 1.2.4.  >> >> >>I > Testing it now, and will report back later.  It would be nice if gzip =   =   > respected 0 > version incrementation instead of overwriting. > < > HAFNER> dir $1$DGA2:[000000]common.sav*/size=3Dunit=3Dbyte > Directory $1$DGA2:[000000] > COMMON.SAV;1         20.49GB > COMMON.SAV-GZ;1       5.03GB > I BTW  the zipped file above was not derived from that common.sav (that wa=  s 5 derived from an older copy) using the new gzip  I get  COMMON.SAV-GZ;1      12.36GB  . so a reduction from 20.49GB to 12.36GB  or 40%     > FREJA> gzip COMMON.SAVG > gzip: $1$DGA2:[000000]COMMON.SAV-gz already exists; do you wish to  =    > overwrite (y
 > or n)? y   ------------------------------  % Date: Sat, 01 Jul 2006 12:06:48 -0700 ' From: glenn everhart <everhart@gce.com> P Subject: Re: zipping large files (was Re: Info-ZIP's Zip V2.32 is now available)$ Message-ID: <44A6C7C8.20801@gce.com>   Tom Linden wrote: H > On Fri, 30 Jun 2006 09:13:25 -0700, Tom Linden <tom@kednos.com> wrote: > 4 >> On Thu, 29 Jun 2006 11:28:41 -0700, Hoff Hoffman # >> <hoff-remove-this@hp.com> wrote:  >> >>> Tom Linden wrote:  >>> A >>>> Do you have it for Alpha as well?  If so, could you post it   >>>> somewhere please? >>> F >>>    gzip 1.3.3 and likely 1.3.5-1 (if not later) will be generally I >>> available on the Freeware V8.0 distribution.  (Tom now has a copy of  J >>> an OpenVMS Alpha gzip port to look at; he probably didn't realize it, ; >>> but he just volunteered to test a gzip port for me. :-)  >>> ' >>>> How is it an improvement on 1.2.4?  >>> I >>>    Other than the large-file support that I centrally needed as part  C >>> of compressing the OpenVMS I64 DVD kits, I didn't particularly  D >>> investigate the details of the changes made to gzip after 1.2.4. >>>  >>>  >>> I >> Testing it now, and will report back later.  It would be nice if gzip   >> respected1 >> version incrementation instead of overwriting.  >>9 >> HAFNER> dir $1$DGA2:[000000]common.sav*/size=unit=byte  >> Directory $1$DGA2:[000000]  >> COMMON.SAV;1         20.49GB  >> COMMON.SAV-GZ;1       5.03GB  >>K > BTW  the zipped file above was not derived from that common.sav (that was 7 > derived from an older copy) using the new gzip  I get  > COMMON.SAV-GZ;1      12.36GB > 0 > so a reduction from 20.49GB to 12.36GB  or 40% >  >  >> FREJA> gzip COMMON.SAV F >> gzip: $1$DGA2:[000000]COMMON.SAV-gz already exists; do you wish to  >> overwrite (y  >> or n)? y  >   C The difference in compression is large here. I wonder: what is the  F /group size that was used in the two originals? If the first had 0 so D there were no xor blocks, and the second had perhaps the default, I H would be totally UNsurprised by the observed difference. XOR blocks are F deadly for adaptive algorithms that just try to treat them as part of  the "normal" stream.  D If the contents and the Backup factors like size of xor groups (and I record size: the backup record headers also compress less well than most  I data and small blocksize will tend to compress worse than large) are the  G same, then the difference in size of the result is really puzzling and   suggests something wrong.    Glenn Everhart   ------------------------------   End of INFO-VAX 2006.363 ************************