|
|
|
|
|
|
| Author |
Message |
Larry Kilgallen
*nix forums Guru
Joined: 05 Mar 2005
Posts: 729
|
 Posted: Thu Jun 15, 2006 4:41 am Post subject:
Re: Slowin' machine while zipping or deleting big binary files
|
|
|
In article <1150302397.812619.17100@f6g2000cwb.googlegroups.com>, "xxrmanza" <rrmj@gmv.es> writes:
| Quote: | thank you all for your help.
The winner is : highwater mark!
was enabled. As soon as I set it to nohighwater it works splendid.
|
I do not see how highwater marking could affect file deletion,
although erase-on-delete would.
If ZIP is inefficient in the fact of highwatermarking, I think
there is a flaw in the coding of ZIP. This seems likely since
many ZIP programs are ported from other systems. To work on a
highwater marking disk, write the file in strictly sequential
order. Otherwise, blocks will have to be zeroed in advance. |
|
| Back to top |
|
 |
JF Mezei
*nix forums Guru
Joined: 21 Jul 2005
Posts: 2556
|
| Posted: Thu Jun 15, 2006 6:54 am Post subject:
Re: Slowin' machine while zipping or deleting big binary files
|
|
|
xxrmanza wrote:
| Quote: |
thank you all for your help.
The winner is : highwater mark!
|
Beware of the security implication of this.
With highwater marking disabled, when you create a file with an
allocation of say 1000 blocks, you are able to read the former contents
that were physically located in the blocks that are now allocated to
your file.
When it is enabled, the system automatically zeroes a block that is
being accessed when that block is beyond the current end of file marker. |
|
| Back to top |
|
|
Bob Koehler
*nix forums Guru
Joined: 25 Jul 2005
Posts: 1078
|
| Posted: Thu Jun 15, 2006 12:24 pm Post subject:
Re: Slowin' machine while zipping or deleting big binary files
|
|
|
In article <YJEypI1TNzIB@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
| Quote: |
If ZIP is inefficient in the fact of highwatermarking, I think
there is a flaw in the coding of ZIP. This seems likely since
many ZIP programs are ported from other systems. To work on a
highwater marking disk, write the file in strictly sequential
order. Otherwise, blocks will have to be zeroed in advance.
|
Although I've read that highwater marking should not make a
significant impact on sequential writes, my experience has been
otherwise.
That's based on tools I think are writing sequencially: TPU,
compilers, and LINK; and code we were writing that used sequential
Fortran or C RTL I/O. |
|
| Back to top |
|
|
AEF
*nix forums Guru
Joined: 27 Jul 2005
Posts: 516
|
| Posted: Thu Jun 15, 2006 12:42 pm Post subject:
Re: Slowin' machine while zipping or deleting big binary files
|
|
|
Larry Kilgallen wrote:
| Quote: | In article <1150302397.812619.17100@f6g2000cwb.googlegroups.com>, "xxrmanza" <rrmj@gmv.es> writes:
thank you all for your help.
The winner is : highwater mark!
was enabled. As soon as I set it to nohighwater it works splendid.
I do not see how highwater marking could affect file deletion,
although erase-on-delete would.
If ZIP is inefficient in the fact of highwatermarking, I think
there is a flaw in the coding of ZIP. This seems likely since
many ZIP programs are ported from other systems. To work on a
highwater marking disk, write the file in strictly sequential
order. Otherwise, blocks will have to be zeroed in advance.
|
Wouldn't a SET RMS/EXTEND=big-number help when making a large zip file?
(big-number should be something like 5000 or larger)
AEF |
|
| Back to top |
|
|
Hoff Hoffman
*nix forums Guru
Joined: 22 Jul 2005
Posts: 572
|
| Posted: Thu Jun 15, 2006 1:47 pm Post subject:
Re: Slowin' machine while zipping or deleting big binary files
|
|
|
AEF wrote:
| Quote: | Wouldn't a SET RMS/EXTEND=big-number help when making a large zip file?
(big-number should be something like 5000 or larger)
|
Current zip provides appropriate extension sizes for its file
operations, IIRC. There are other fixes to zip (you want 2.31, or later
as available) and unzip (get 5.52, or later as available) that make use
of the current revisions recommended, too.
Visit <http://www.info-zip.org.>
The next OpenVMS Freeware is shipping with these bits, as well. |
|
| Back to top |
|
|
Steven M. Schweda
*nix forums Guru
Joined: 01 Aug 2005
Posts: 300
|
| Posted: Thu Jun 15, 2006 3:30 pm Post subject:
Re: Slowin' machine while zipping or deleting big binary files
|
|
|
From: "AEF" <spamsink2001@yahoo.com>
| Quote: | Larry Kilgallen wrote:
In article <1150302397.812619.17100@f6g2000cwb.googlegroups.com>, "xxrmanza" <rrmj@gmv.es> writes:
thank you all for your help.
The winner is : highwater mark!
was enabled. As soon as I set it to nohighwater it works splendid.
I do not see how highwater marking could affect file deletion,
although erase-on-delete would.
If ZIP is inefficient in the fact of highwatermarking, I think
there is a flaw in the coding of ZIP.
|
There was, before Zip 2.31. (And it wasn't the only one. And it
probably wasn't the last one, either, but anyone is welcome to
contribute complaints and/or fixes.)
Of course, as has been noted already, the original poster did not
mention the Zip version involved.
| Quote: | This seems likely since
many ZIP programs are ported from other systems.
|
It would be more accurate to say that the Info-ZIP programs are
developed more or less simultaneously on multiple systems, according to
the preferences of the developers. Unlike with the typical GNU program,
the Info-ZIP developers tend to be aware of code portability problems.
In my limited travels, I have found no other freeware developers who are
more interested in accomodating VMS (features and limitations).
| Quote: | To work on a
highwater marking disk, write the file in strictly sequential
order. Otherwise, blocks will have to be zeroed in advance.
|
And, more important, set the SQO (sequential access only) bit, to
inform the system that you'll be doing that, as merely writing strictly
sequentially does not fix the problem.
| Quote: | Wouldn't a SET RMS/EXTEND=big-number help when making a large zip file?
(big-number should be something like 5000 or larger)
|
Yes, but a larger extend quantity also locks the disk for longer
periods when highwater marking is anabled, and the SQO bit is not set.
From: Hoff Hoffman <hoff-remove-this@hp.com>
| Quote: | Current zip provides appropriate extension sizes for its file
operations, IIRC. There are other fixes to zip (you want 2.31, or later
as available) and unzip (get 5.52, or later as available) that make use
of the current revisions recommended, too.
Visit <http://www.info-zip.org.
The next OpenVMS Freeware is shipping with these bits, as well.
|
Indeed. It's nice to see that someone remembered. For the original,
longer, more rambling discussion of [Un]Zip v. highwater marking, see,
for example:
http://groups.google.com/group/comp.os.vms/browse_thread/thread/e40c7dbd70bab7c9/f8a01603c0ff49b3
Of course, "appropriate" is open to interpretation, but the current
behavior (Zip 2.31 and up, subject to complaints) is to set the extend
quantity to 16384, subject to an override by way of SET RMS_DEFAULT
/EXTEND_QUANTITY. The source code is available for inspection. On the
other end, in UnZip 5.52 (and up, ...), because the file sizes are
stored in the archive, it's possible to allocate the whole of each
extracted file when it's created, and that's what UnZIP does (now).
(And thanks to the miracle of the SQO bit, it no longer locks the target
disk for extended periods when allocating space for a large file.)
Note that, for trivially small test cases, 16384 is too big, and
actually slows things down a little, but my inability to choose _the_
perfect value is why the override was implemented.
------------------------------------------------------------------------
Steven M. Schweda sms@antinode-org
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547 |
|
| Back to top |
|
|
norm.raphael@metso.com
*nix forums Guru Wannabe
Joined: 02 Jun 2005
Posts: 227
|
| Posted: Tue Jun 20, 2006 1:22 pm Post subject:
Re: [VMS 8.2] UPDATE ECO 3 is out
|
|
|
If you would run
$PRODUCT LIST VMS732_UPDATE
answer the questions
and check the ".RELEASE_NOTES files,
you could tell us.
peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) wrote on 06/20/2006
11:29:55 AM:
|
|
| Back to top |
|
|
norm.raphael@metso.com
*nix forums Guru Wannabe
Joined: 02 Jun 2005
Posts: 227
|
| Posted: Tue Jun 20, 2006 1:23 pm Post subject:
Re: [VMS 8.2] UPDATE ECO 3 is out
|
|
|
If you would run
$PRODUCT LIST VMS732_UPDATE
answer the questions
and check the ".RELEASE_NOTES files,
you could tell us.
peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) wrote on 06/20/2006
11:29:55 AM:
|
|
| Back to top |
|
|
norm.raphael@metso.com
*nix forums Guru Wannabe
Joined: 02 Jun 2005
Posts: 227
|
| Posted: Tue Jun 20, 2006 1:41 pm Post subject:
Re: [VMS 7.3-2] UPDATE ECO 7 is out
|
|
|
If you would run
$PRODUCT LIST VMS732_UPDATE
answer the questions
and check the ".RELEASE_NOTES" files,
you could tell us.
peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) wrote on 06/20/2006
11:23:27 AM:
|
|
| Back to top |
|
|
Steven M. Schweda
*nix forums Guru
Joined: 01 Aug 2005
Posts: 300
|
| Posted: Thu Jun 29, 2006 4:24 am Post subject:
Re: zipping large files (was Re: Info-ZIP's Zip V2.32 is now available)
|
|
|
From: JF Mezei <jfmezei.spamnot@teksavvy.com>
| Quote: | Hey Mr SMS, could you provide a description of the various ZIP/UNZIPs
that are available on VMS ?
|
There are old ones, current ones, and future ones.
Recently current Now current Future
-------+------------------+-------------+--------
Zip 2.31 2.32 3.x
UnZip 5.52 5.52 6.x
Old ones are older than the "recently current" ones. For a variety of
reasons, I would not use anything older than the "recently current"
ones. Some "future" ones are currently available as BETA source kits,
and offer such attractive features as large-file support. I encourage
everyone to try them (Zip 3.0e, UnZip 6.00c), as we'd like to find any
problems before the general release. (Hold your breath.)
| Quote: | Even on my own VAXes, I am confused. Some node has an UNZIP in the
DCLTABLES, the others don't, so I suspect this one came with MMS. There
is some old unzip littered in varous directories over the years.
|
I'm not aware of any Info-ZIP stuff shipping as part of MMS or any
other DEC/Compaq/HP product (other than the odd self-extracting Zip
archive). I know of no standard installation procedure which would
affect the system DCL tables, but I suppose that anyone with permission
could add "/TABLE = <anything>" to the suggested SET COMMAND command.
(I don't use SET COMMAND for these things, as I find that the
foreign-command symbol scheme does what I need, with less potential for
trouble.)
Naturally, I deny any responsibility for any clutter which you might
find on your systems.
| Quote: | I'd like to streamline this and have a single ZIP/UNZIP in a
known/standard location.
|
That would be fine with me.
| Quote: | I was under the impression that you were the
"official" maintainer of zip/unzip for VMS, hut now, MR Goatley comes
out with Info-Zip which leads me to believe there are different source
trees/products around.
|
I'm just a (hard[ly]-working) flunky (who got into this whole thing
by accident -- See "Zip -VV"). Mr. Goatley has been providing VMS
binary distributions for a long time, and I'm certainly willing to let
him continue to do so. (How could I stop him? And why would I?) I
believe that he added some IA64 support to the builders which he was
distributing before the official source kits included that feature. The
official personel list is available at:
http://www.info-zip.org/#People
Pointers to official source and binary kits are available nearby.
------------------------------------------------------------------------
Steven M. Schweda sms@antinode-org
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547 |
|
| Back to top |
|
|
Hunter Goatley
*nix forums Guru Wannabe
Joined: 13 Jun 2005
Posts: 107
|
| Posted: Thu Jun 29, 2006 1:55 pm Post subject:
Re: zipping large files (was Re: Info-ZIP's Zip V2.32 is now available)
|
|
|
Steven M. Schweda wrote:
| Quote: |
I was under the impression that you were the
"official" maintainer of zip/unzip for VMS, hut now, MR Goatley comes
out with Info-Zip which leads me to believe there are different source
trees/products around.
I'm just a (hard[ly]-working) flunky (who got into this whole thing
by accident -- See "Zip -VV"). Mr. Goatley has been providing VMS
binary distributions for a long time, and I'm certainly willing to let
him continue to do so. (How could I stop him? And why would I?) I
believe that he added some IA64 support to the builders which he was
distributing before the official source kits included that feature. The
official personel list is available at:
http://www.info-zip.org/#People
Pointers to official source and binary kits are available nearby.
|
And many thanks to Steven for stepping in when he did. I've been part
of the Info-ZIP team since '91 or so (I did the original port to Alpha
and the original CLI version of Zip/UnZip), and as Steven said, I've
been distributing VMS binaries via my freeware archive all these
years. Over the past few years, I've had less time to devote to the
project. Fortunately for all of us, Steven joined the team and has
done a lot of great work on Zip and UnZip, both the VMS-specific
features and general features.
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
PreciseMail Anti-Spam Gateway for OpenVMS, Tru64, Solaris, & Linux
goathunter@goatley.com http://www.goatley.com/hunter/ |
|
| Back to top |
|
|
Steven M. Schweda
*nix forums Guru
Joined: 01 Aug 2005
Posts: 300
|
| Posted: Sun Jul 02, 2006 7:09 pm Post subject:
Re: zipping large files (was Re: Info-ZIP's Zip V2.32 is now available)
|
|
|
From: Hoff Hoffman <hoff-remove-this@hp.com>
| Quote: | I have a gzip port (1.3.3?) that has been in use for OpenVMS I64
DVDs, and we regularly use it for files beyond what zip can manage.
(IIRC, current versions of zip tend to tip over at or near 2GB.)
|
I've been fooling around lately with gzip 1.3.5 (large files, better
RMS default parameters, command-line case preservation -- the usuals).
In my (limited) testing, the only problem I've seen with large files in
1.2.4 (or a small-file 1.3.5) is the defective calculation of the
fractional space saved. For example (10156256 blocks -> 4232287
blocks):
Small-file (1.2.4 or 1.3.5):
VMS732X8_GZ.IMG;1 10156256/10156317 2-JUL-2006 00:15:17.78 (RWED,RWED,RE,)
ALP $ gzip -vv DKB300:[ZT]VMS732X8_GZ.IMG
DKB300:[ZT]VMS732X8_GZ.IMG;1: -139.4% -- replaced with DKB300:[ZT]VMS732X8_GZ.
IMG-gz
VMS732X8_GZ.IMG-GZ;1 4232287/4232322 1-JUL-2006 18:18:44.75 (RWED,RWED,RE,)
or (large before and after, not much actual compression):
BSB_ORIG.ZIP;1 8464574/8464575 27-NOV-2004 21:40:58.07 (RWED,RWED,RE,)
ALP $ ; gzip -v BSB_ORIG.ZIP
DKB300:[ZT]BSB_ORIG.ZIP;1: 47.3% -- replaced with DKB300:[ZT]BSB_ORIG.ZIP-
gz
BSB_ORIG.ZIP-GZ;1 8428600/8428626 2-JUL-2006 01:07:58.00 (RWED,RWED,RE,)
Large-file (1.3.5):
ALP $ gzl -d -v DKB300:[ZT]VMS732X8_GZ.IMG-gz
DKB300:[ZT]VMS732X8_GZ.IMG-GZ;1: 58.3% -- replaced with DKB300:[ZT]VMS73
2X8_GZ.IMG
The resulting files look the same to me. Was there ever any problem
with the old gzip other than the bad message? (Because gzip does not
dance around (seek/tell) in the archive the way Zip or UnZip does, this
should not amaze.)
------------------------------------------------------------------------
Steven M. Schweda sms@antinode-org
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547 |
|
| Back to top |
|
|
Steven M. Schweda
*nix forums Guru
Joined: 01 Aug 2005
Posts: 300
|
| Posted: Thu Jul 06, 2006 3:25 am Post subject:
Re: zipping large files (was Re: Info-ZIP's Zip V2.32 is now available)
|
|
|
| Quote: | I've been fooling around lately with gzip 1.3.5 (large files, better
RMS default parameters, command-line case preservation -- the usuals).
[...]
|
For those desperate for amusement:
http://antinode.org/dec/sw/gzip.html
My guess is that it'll work on anything back to VMS V5.4, but no
bets. Large-file support requires something a bit newer than that.
There's no special ODS5 code anywhere (yet), so don't be amazed if it
has trouble there. As always, complaints are welcome.
I'm trying to get in touch with the official gzip developers in the
hope of getting the VMS stuff updated in the official kit. No bets on
that, either.
------------------------------------------------------------------------
Steven M. Schweda sms@antinode-org
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547 |
|
| Back to top |
|
|
Koska, John C. (LNG-ALB)
*nix forums beginner
Joined: 21 Feb 2005
Posts: 5
|
| Posted: Fri Jul 07, 2006 2:09 am Post subject:
RE: Moron! Re: OT: Ken Lay dead
|
|
|
Please!!! Robert Maxwell aka Ján Ludvik Hoch! My former boss got bumped off by the Massad, well really the CIA, off the Canary Islands for being an Israeli spy of unspeakable offenses against American and European peoples. Good riddens to his kind, although I understand why he was the way he was. A sad life in the end. He could have been much better, but was a hero for Israeli for stealing all sorts of technology, and providing the ability to compromise other intelligence organizations and accomplishing corporate espionage for his masters.
:) jck
-----Original Message-----
From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
Sent: Thursday, July 06, 2006 6:51 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Moron! Re: OT: Ken Lay dead
Hi Steven,
| Quote: | Of course, the loosers who frequent this group might be more likely
to claim that "Ken Laid dead." or "Ken Layed dead.", instead.
|
I am sick of this incompetence; I think you'll find it's "loser's" :-)
Cheers Richard Maher
PS. (Or should that be "its"?)
BTW. Those from the UK know well that ken is now living it up with Robert Maxwell and the pension fund.
"Steven M. Schweda" <sms@antinode.org> wrote in message news:06070617151022_2024476F@antinode.org...
| Quote: | Can I assume that everyone has noticed that "Ken Lay dead." could
be construed as a complete sentence (with excessive capitalization as
its only grammatical defect)?
Of course, the loosers who frequent this group might be more likely
to claim that "Ken Laid dead." or "Ken Layed dead.", instead.
----------------------------------------------------------------------
--
Steven M. Schweda sms@antinode-org
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547 |
|
|
| Back to top |
|
|
Nomen Nescio
*nix forums addict
Joined: 05 Apr 2005
Posts: 77
|
| Posted: Sat Jul 08, 2006 7:00 am Post subject:
J F at his best!!!
|
|
|
Insane Canadian psychopath JF Mezei planted this IED:
| Quote: | mrtravel wrote:
How can anyone stabilized the middle east where there are multiple
internal groups fighting for control with each other?
Your regime had been warned by former allies that going into Iraq would
destabilise the situation BIG TIME. And this is why none of the
neighbours, except Kurwait supported the USA invasion of Iraq. Hussein
was an evil leader that was contained, and more importantly, that
contained the bad guys within his country.
Your regime chose to disregard worldwide advice to leave Iraq alone, and
instead use money and coercion to enlist some other countries (except
Australia which begged to be part of this war crime without expecting
anything in return).
CanKt wait for the day when Bush will have killed more americans because
of his terrorist attack on Iraq than Bin Ladin's terrorist attack on
USA. It is coming this year. Excpect major announcement of troup
widthdrawals just before that milestone is reached in order to
pre-emtively defise the bad news of Bush/Cheney/Rumsfeld/Wolfowitz
having killed more americans than Bin Ladin.
Of course, the USA doesn't care about how many Iraqis they have killed.
This is more than 5 times more than the number of americans killed by
Ossama. Yet, there is now "Wanted dead or alive" sign for the Bush
regime who have committed even bigger crimes than Bin Landin.
|
http://groups.google.com/group/soc.culture.quebec/msg/880c1fd75171d44c |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 5:58 am | All times are GMT
|
|
Credit Counseling | Landscape Photos | Mobile Phone | Credit Check | Loans
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Not Unix
»
VMS
