Unexpected error using ZIP for OpenVMS

[RobertsonEricW]

I bumped across this error a while ago but am only now getting around
to posting it. Just curious if anybody else has seen a similar
problem. This is not what I would call a critical error. At the time I
first encountered this error, I was using ZIP for OpenVMS because I
happened to be logged into my OpenVMS machine when I became aware that
I wanted to send these files to somebody else in an E-mail. But, I
don't think that this particular issue will be frequently encountered.
All other attempts to ZIP files with other more conventional RMS
record formats on OpenVMS have executed without problems.

The output below is from an attempt to ZIP windows DLL files on
OpenVMS Alpha V8.3 that were created by Windows on a SAMBA share
hosted on my OpenVMS machine. As far as windows was concerned the DLLs
"looked" normal as it viewed them through SAMBA. Its possible that the
RMS Record Format of "Stream, maximum 0 bytes, longest 32767 bytes" is
confusing things. But that is only a guess.

$ ZIP "-v"
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software
license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon. Please send bug reports to
the authors using the web page at www.info-zip.org; see README for
details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.

Compiled with DEC C V7.3-009 for OpenVMS (V8.3 Alpha) on May 5 2011.

Zip special compilation options:
USE_EF_UT_TIME (store Universal Time)
VMS_PK_EXTRA
BZIP2_SUPPORT (bzip2 library version 1.0.6, 6-
Sept-2010)
bzip2 code and library copyright (c) Julian R Seward
(See the bzip2 license for terms of use)
SYMLINK_SUPPORT (symbolic links supported, if C RTL
permits)
LARGE_FILE_SUPPORT (can read and write large files on file
system)
ZIP64_SUPPORT (use Zip64 to store large files in
archives)
[encryption, version 2.91 of 05 Jan 2007] (modified for Zip 3)

Encryption notice:
The encryption code of this program is not copyrighted and is
put in the public domain. It was originally written in Europe
and, to the best of our knowledge, can be freely distributed
in both source and object forms from any country, including
the USA under License Exception TSU of the U.S. Export
Administration Regulations (section 740.13(e)) of 6 June 2002.

Zip environment options:
ZIP_OPTS: [none]
ZIPOPT: [none]
$ zip test.zip [-...]*.*;*
adding: [.usr.robertson.test.MSVCRuntimeDLLS.temp] (stored 0%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.3053_x-ww_b80fa8ca] (stored 0%
)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.4053_x-ww_e6967989] (stored 0%
)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_0de06acd] (stored 0%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.762_x-ww_6b128700] (stored 0%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.DebugCRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_f75eb16c] (stored
0%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.3053_x-ww_b80fa8ca]msvcm80.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.3053_x-ww_b80fa8ca]msvcm80.dll
(deflated 69%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.3053_x-ww_b80fa8ca]msvcp80.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.3053_x-ww_b80fa8ca]msvcp80.dll
(deflated 59%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.3053_x-ww_b80fa8ca]msvcr80.dll
(deflated 49%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.4053_x-ww_e6967989]msvcm80.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.4053_x-ww_e6967989]msvcm80.dll
(deflated 69%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.4053_x-ww_e6967989]msvcp80.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.4053_x-ww_e6967989]msvcp80.dll
(deflated 59%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.4053_x-ww_e6967989]msvcr80.dll
(deflated 49%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_0de06acd]msvcm80.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.42_x-ww_0de06acd]msvcm80.dll
(deflated 69%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_0de06acd]msvcp80.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.42_x-ww_0de06acd]msvcp80.dll
(deflated 60%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_0de06acd]msvcr80.dll (
deflated 50%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.762_x-ww_6b128700]msvcm80.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.762_x-ww_6b128700]msvcm80.dll
(deflated 69%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.762_x-ww_6b128700]msvcp80.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.762_x-ww_6b128700]msvcp80.dll
(deflated 60%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.762_x-ww_6b128700]msvcr80.dll
(deflated 50%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.DebugCRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_f75eb16c]msvcm80d
.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.DebugCRT_1fc8b3b9a1e18e3b_
8^.0^.50727^.42_x-ww_f75eb16c]msvcm80d.dll
(deflated 74%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.DebugCRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_f75eb16c]msvcp80d
.dll

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.DebugCRT_1fc8b3b9a1e18e3b_
8^.0^.50727^.42_x-ww_f75eb16c]msvcp80d.dll
(deflated 71%)
adding:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.DebugCRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_f75eb16c]msvcr80d
.dll (deflated 60%)
$ dir/full [-...]*.dll

Directory DISK_USERS:
[usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.3053_x-ww_b80fa8ca]

msvcm80.dll;1 File ID: (235254,1,0)
Size: 936/944 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:25:57.70
Revised: 25-JUL-2008 11:17:20.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:39.35
Attributes: 25-JUL-2008 11:17:20.00
Modified: 25-JUL-2008 11:17:20.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 944, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcp80.dll;1 File ID: (235255,1,0)
Size: 1090/1104 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:25:58.28
Revised: 25-JUL-2008 11:17:20.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:39.56
Attributes: 25-JUL-2008 11:17:20.00
Modified: 25-JUL-2008 11:17:20.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 1104, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcr80.dll;1 File ID: (235256,1,0)
Size: 1242/1248 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:25:59.07
Revised: 25-JUL-2008 11:17:20.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:39.79
Attributes: 25-JUL-2008 11:17:20.00
Modified: 25-JUL-2008 11:17:20.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 1248, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

Total of 3 files, 3268/3296 blocks.

Directory DISK_USERS:
[usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.4053_x-ww_e6967989]

msvcm80.dll;1 File ID: (235258,1,0)
Size: 936/944 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:26:09.17
Revised: 12-JUL-2009 01:08:14.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:39.92
Attributes: 12-JUL-2009 01:08:14.00
Modified: 12-JUL-2009 01:08:14.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 944, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcp80.dll;1 File ID: (235259,1,0)
Size: 1084/1088 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:26:09.88
Revised: 12-JUL-2009 01:09:20.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:40.05
Attributes: 12-JUL-2009 01:09:20.00
Modified: 12-JUL-2009 01:09:20.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 1088, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcr80.dll;1 File ID: (235260,1,0)
Size: 1236/1248 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:26:10.51
Revised: 12-JUL-2009 01:12:06.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:40.28
Attributes: 12-JUL-2009 01:12:06.00
Modified: 12-JUL-2009 01:12:06.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 1248, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

Total of 3 files, 3256/3280 blocks.

Directory DISK_USERS:
[usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_0de06acd]

msvcm80.dll;1 File ID: (235235,2,0)
Size: 936/944 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:25:35.56
Revised: 22-SEP-2005 23:48:08.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:40.41
Attributes: 22-SEP-2005 23:48:08.00
Modified: 22-SEP-2005 23:48:08.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 944, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcp80.dll;1 File ID: (235236,2,0)
Size: 1072/1072 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:25:36.60
Revised: 22-SEP-2005 23:48:08.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:40.54
Attributes: 22-SEP-2005 23:48:08.00
Modified: 22-SEP-2005 23:48:08.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 1072, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcr80.dll;1 File ID: (235237,2,0)
Size: 1224/1232 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:25:38.06
Revised: 22-SEP-2005 23:48:06.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:40.77
Attributes: 22-SEP-2005 23:48:06.00
Modified: 22-SEP-2005 23:48:06.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 1232, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

Total of 3 files, 3232/3248 blocks.

Directory DISK_USERS:
[usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.762_x-ww_6b128700]

msvcm80.dll;1 File ID: (235239,2,0)
Size: 936/944 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:25:48.60
Revised: 1-DEC-2006 21:54:32.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:40.89
Attributes: 1-DEC-2006 21:54:32.00
Modified: 1-DEC-2006 21:54:32.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 944, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcp80.dll;1 File ID: (235240,2,0)
Size: 1072/1072 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:25:49.24
Revised: 1-DEC-2006 21:54:34.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:41.03
Attributes: 1-DEC-2006 21:54:34.00
Modified: 1-DEC-2006 21:54:34.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 1072, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcr80.dll;1 File ID: (235241,2,0)
Size: 1224/1232 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:25:49.96
Revised: 1-DEC-2006 21:54:32.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:41.25
Attributes: 1-DEC-2006 21:54:32.00
Modified: 1-DEC-2006 21:54:32.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 1232, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

Total of 3 files, 3232/3248 blocks.

Directory DISK_USERS:
[usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.DebugCRT_1fc8b3b9a1e18e3b_8^.
0^.50727^.42_x-ww_f75eb16
c]

msvcm80d.dll;1 File ID: (235262,1,0)
Size: 1984/1984 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:27:37.85
Revised: 22-SEP-2005 23:48:08.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:41.51
Attributes: 22-SEP-2005 23:48:08.00
Modified: 22-SEP-2005 23:48:08.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 1984, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcp80d.dll;1 File ID: (235263,1,0)
Size: 2008/2016 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:27:38.87
Revised: 22-SEP-2005 23:48:08.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:41.81
Attributes: 22-SEP-2005 23:48:08.00
Modified: 22-SEP-2005 23:48:08.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 2016, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

msvcr80d.dll;1 File ID: (235264,1,0)
Size: 2288/2288 Owner: [ROBERTSON]
Created: 22-JUL-2011 11:27:39.80
Revised: 22-SEP-2005 23:48:08.00 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: 3-DEC-2011 05:43:42.28
Attributes: 22-SEP-2005 23:48:08.00
Modified: 22-SEP-2005 23:48:08.00
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 2288, Extend: 0, Global buffer count:
0, No version limit
Record format: Stream, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List: None
Client attributes: None

Total of 3 files, 6280/6288 blocks.

Grand total of 5 directories, 15 files, 19268/19360 blocks.
$

[Steven Schweda]

On Dec 3, 5:22 am, RobertsonEricW <robertsoner...@netzero.net> wrote:

> [...] Just curious if anybody else has seen a similar
> problem. [...]

I don't recall anyone else complaining.

> $ ZIP "-v"
> [...]

Thanks for the complete info. It's a rare treat. (But
you never need to quote a "-v", only stuff with upper-case
content, like, say, "-V". Speaking of which, you might try
adding "-V" to see if that helps.)

Any chance that I can get one or two of these files for
investigation? There's a "[.INPUT]" directory on my
anonymous FTP server (antinode.info) which should be happy to
receive a contribution. A "zip -V" (or even BACKUP) package
should preserve enough attributes to maintain the
trouble-causing capability of these things.

Just when I thought that the last bug had been fixed...

[Steven Schweda]

On Dec 3, 8:23 am, Steven Schweda <sms.antin...@gmail.com> wrote:

> Any chance that I can get one or two of these files for

> investigation? [...]

No need. I can create one which does the job:

ALP $ zip3l long_rec.zip long_rec.*
adding: long_rec.c (deflated 37%)
adding: LONG_REC.DAT

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer

zip warning: could not open for reading: LONG_REC.DAT
adding: long_rec.EXE (deflated 75%)
adding: long_rec.OBJ (deflated 58%)

zip warning: Not all files were readable
files/entries read: 3 (6.4K bytes) skipped: 1 (128K bytes)

"Record format: Stream" (with a long record) seems to
cause trouble for fread(). (At least the way we open the
file, it does). "zip -V" uses a different I/O scheme (QIO),
so it seems to be less bothered by this:

ALP $ zip3l -V long_rec-V.zip long_rec.*
adding: long_rec.c (deflated 34%)
adding: LONG_REC.DAT (deflated 100%)
adding: long_rec.EXE (deflated 75%)
adding: long_rec.OBJ (deflated 58%)
adding: long_rec.zip (stored 0%)

Interestingly, "Record format: Stream_LF" seems not to
suffer from the same behavior (even without an LF in the
file).

I'll look around and see if I can find a clever way to
deal with this (without breaking too much).

And, of course, thanks for the interesting report.

[RobertsonEricW]

Steven,

No need to thank me. These days cut and paste makes it very easy to
inundate you with information regarding a bug (or bugs as the case may
be).

Actually, it is I who should be thanking you. First for maintaining
ZIP/UNZIP for OpenVMS and second for your prompt investigation and
report of the problem. The company I work for PAYS for support from HP
that mostly seems incapable of providing the same level of promptness
and clarity that you have provided for free.

So, thanks again for your continued support and contributions to the
OpenVMS community.

Eric

[Phillip Helbig---undress to reply]

In article
<cd9f8b76-dbf6-4928...@q11g2000vbq.googlegroups.com>,

RobertsonEricW <roberts...@netzero.net> writes:

> Actually, it is I who should be thanking you. First for maintaining
> ZIP/UNZIP for OpenVMS and second for your prompt investigation and
> report of the problem. The company I work for PAYS for support from HP
> that mostly seems incapable of providing the same level of promptness
> and clarity that you have provided for free.
>
> So, thanks again for your continued support and contributions to the
> OpenVMS community.

I second that. When I'm rich, I'll hire SMS. :-)

[Steven Schweda]

On Dec 3, 7:55 pm, RobertsonEricW <robertsoner...@netzero.net> wrote:

> [...] These days cut and paste makes it very easy [...]

Not easy enough for some of the victims. I'm routinely
amazed by how little info some complainers provide.

I haven't done enough testing yet, but, if you're feeling
adventurous, the following replacement modules seem (at first
glance) to do the job (and to be harmless):

http://antinode.info/ftp/info-zip/zip30/vms/vms.c
http://antinode.info/ftp/info-zip/zip30/vms/zipup.h

To get a slightly different program version string (probably
wise):

http://antinode.info/ftp/info-zip/zip30/revision.h

(There's other stuff in that tree, too, unrelated to this
problem, but some of it is potentially interesting.)

Unless problems are found with these new modules, similar
changes should appear in the next Zip beta kit. Complaints,
especially on these proposed changes, remain welcome.

[Steven Schweda]

> I bumped across this error a while ago [...]

It's been around since at least "Zip 2.0 (Sept 7th 1993)".
(I prefer Zip bugs which are old enough to vote, because they
can't be my fault.)

> I haven't done enough testing yet, [...]

I've now tried the proposed fix with long and short
records in Stream, Stream_CR, and Stream_LF (and also
Undefined), and the results all look plausible to me.
DIFFERENCES may have some trouble with the long records, but
BACKUP /COMPARE seems happy enough. Other record types
should be unaffected by these changes. What could go wrong?

For the record, accessing these long-record files over
DECnet could lead to similar but different errors. For
example:

zip warning: non-translatable vms error code: 0x183A2
%rms-e-netbts, network buffer too small for !ul byte record

zip warning: could not open for reading:

[.UTILITY.SOURCE.ZIP.DEV]LONG_REC_CR.DAT

The proposed fix seems to clear those, too.

Pending further complaints, I believe that I'm satisfied.

[RobertsonEricW]

Steven,

Thanks again for your prompt service! I will download the updated
source modules and try them out later this week. Right now I am REALLY
busy dealing with clients that all require far and distant travel.

Regards,

Eric

[Jeremy Begg]

Hi Steven,

I too ran into this issue a couple of months back but it wasn't critical so
I ignored it.

I've now tested your changes and have found just one minor shortcoming.

The file being ZIPped has these attributes:

VAX-11 RMS attributes
Record type: RMS-11 stream
File organization: Sequential
Record attributes: Implied carriage control
Record size: 0
Highest block: 1552
End of file block: 1553
End of file byte: 0
Bucket size: 0
Fixed control area size: 0
Maximum record size: 0
Default extension size: 0
Global buffer count: 0
Directory version limit: 0

I ZIPped it using your latest mods to ZIP (with LARGE FILE support) then
UNZIPped it using both UNZIP 5.52 and UNZIP 6.0. The resulting unzipped
file has these attributes:

VAX-11 RMS attributes
Record type: LF-terminated stream
File organization: Sequential
Record attributes: Implied carriage control
Record size: 0
Highest block: 1552
End of file block: 1553
End of file byte: 0
Bucket size: 0
Fixed control area size: 0
Maximum record size: 0
Default extension size: 16384
Global buffer count: 0
Directory version limit: 0

The Record type has changed from "Stream" to "StreamLF".

The actual bytes on disk appear to be the same as the original.
(I tested this on Itanium on VMS 8.4 and 8.3-1H1. Both produced the same
result. BACKUP/COMPARE on V8.4 ignored the different record formats but on
V8.3-1H1 it complained about every record!)

Thanks,

Jeremy Begg

[Steven Schweda]

On Dec 11, 11:05 pm, Jeremy Begg <jeremy.removet...@vsm.com.au> wrote:

> I too ran into this issue a couple of months back but it wasn't critical so
> I ignored it.

Passing up a perfectly good reason to complain? What's
wrong with you people?

> I've now tested your changes and have found just one minor shortcoming.

That's a feature, not a shortcoming. If you want VMS/RMS
file attributes to be saved and restored, then use "-V[V]"
(/VMS [= ALL]) on your Zip command. By default, you're lucky
if you get the data right, let alone the meta-data. Zip
saves the bytes (if can manage to read the file). UnZip (on
a non-"-V" archive) might make Stream_LF, Fixed-512, or
Variable-length records, depending on options (such as "-S",
/TEXT = STMLF), and whether Zip thought that the file was
text or binary. I'd need to examine the documentation and/or
the code to see what's true in detail. As usual,
everything's complicated (and the behavior might have changed
in recent years). But I'd be amazed if you could find a way
to get Stream or Stream_CR records out of a non-"-V" archive.

> [...] BACKUP/COMPARE on V8.4 ignored the different record

> formats but on V8.3-1H1 it complained about every record!)

On V8.3 Alpha, BACKUP /COMPARE seemed happy enough in my
testing. I checked it there and on an old VAX system (V5.4
with VAX C V3.1-051). I didn't try it on IA64. (What could
be different between Alpha and IA64? Or between one VMS
version and another?)

[Phillip Helbig---undress to reply]

In article
<237ee74d-3067-4f66...@q9g2000yqe.googlegroups.com>,

Steven Schweda <sms.an...@gmail.com> writes:

> What could
> be different between Alpha and IA64? Or between one VMS
> version and another?)

Now I realize there must have always been an invisible smiley after your
"What could go wrong?" questions. :-)

[Steven Schweda]

On Dec 12, 3:27 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:

> Now I realize [...]

"What could go wrong?" is an abbreviation. The
full-length version is:

What could go wrong? <click> go wrong? <click> go
wrong? <click> [...]

(Not my invention, but it does seem to fit very well into
very many situations.)

[Phillip Helbig---undress to reply]

In article
<b78b6720-2e9e-405d...@l24g2000yqm.googlegroups.com>,

Steven Schweda <sms.an...@gmail.com> writes:

> On Dec 12, 3:27 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
> undress to reply) wrote:
>
> > Now I realize [...]
>
> "What could go wrong?" is an abbreviation. The
> full-length version is:
>
> What could go wrong? <click> go wrong? <click> go
> wrong? <click> [...]

Cue a cartoon character running off of a cliff and hanging in the air
for a few seconds before realizing that he will fall.

[Paul Sture]

On Tue, 13 Dec 2011 09:12:25 +0000, Phillip Helbig---undress to reply
wrote:

And the point there is that he doesn't actually start falling until he
looks down.



--
Paul Sture

[John Reagan]

"Phillip Helbig---undress to reply" <hel...@astro.multiCLOTHESvax.de> wrote
in message news:jc74tp$1h2$1...@online.de...

Actually, the best version was in Westworld with Yul Brynner in 1973.

http://www.imdb.com/title/tt0070909/

Trailer at

http://www.youtube.com/watch?v=dQVWP8fP5To

What could go wrong? go wrong? go wrong? starts around 2:20 but the classic
1973 vintage trailer is a great contrast to Hollywood movies of today.

John

[Paul Sture]

"Shutdown. Shutdown immediately."

That reminds me of efforts to close down, ahem, certain operating systems
in a hurry, only to be greeted by anything from "unknown command" to a
help screen detailing the options.

Thanks for the link.

--
Paul Sture

[Alan Feldman]

On Dec 3, 6:22 am, RobertsonEricW <robertsoner...@netzero.net> wrote:
> I bumped across this error a while ago but am only now getting around
> to posting it. Just curious if anybody else has seen a similar
> problem. This is not what I would call a critical error. At the time I
> first encountered this error, I was using ZIP for OpenVMS because I
> happened to be logged into my OpenVMS machine when I became aware that
> I wanted to send these files to somebody else in an E-mail. But, I
> don't think that this particular issue will be frequently encountered.
> All other attempts to ZIP files with other more conventional RMS
> record formats on OpenVMS have executed without problems.
>
> The output below is from an attempt to ZIP windows DLL files on
> OpenVMS Alpha V8.3 that were created by Windows on a SAMBA share
> hosted on my OpenVMS machine. As far as windows was concerned the DLLs
> "looked" normal as it viewed them through SAMBA. Its possible that the
> RMS Record Format of "Stream, maximum 0 bytes, longest 32767 bytes" is
> confusing things. But that is only a guess.
>
> $ ZIP "-v"
> Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software
> license.
> This is Zip 3.0 (July 5th 2008), by Info-ZIP.
> Currently maintained by E. Gordon.  Please send bug reports to

> the authors using the web page atwww.info-zip.org;see README for
> details.
>
> Latest sources and executables are atftp://ftp.info-zip.org/pub/infozip,
> as of above date; seehttp://www.info-zip.org/for other sites.

> Effective:  <None specified>...
>
> read more »

What is an unexpected error? What if you were expecting an unexpected
error? Aside from writing code, or repeating an action known to cause
a certain error, do you expect a certain error when it happens, making
that error and "expected error"?

"I wasn't expecting an error."

AEF

[Steven Schweda]

On Dec 17, 11:56 am, Alan Feldman <alanfeldma...@gmail.com> wrote:

> What is an unexpected error? [...]

Seriously? Is this really a complicated or otherwise
tricky concept?

Here's an example of an error which I'd expect:

alp $ zip31l d0:[0000000]fred.zip login.com
zip I/O error: no such file or directory
zip error: Could not create output file (d0:[0000000]fred.zip)

The (excessively quoted) original complaint shows an error
which I wouldn't (and didn't) expect. (And don't expect to
see again, in the next Zip beta kit, and beyond.)

> "I wasn't expecting an error."

I wasn't expecting an inquiry so devoid of value. (Call
me an optimist.) Time spent on specious nit-picking might be
better spent on testing the actual code involved here.

Just a thought.

[Paul Sture]

On Sat, 17 Dec 2011 09:56:41 -0800, Alan Feldman wrote:

> What is an unexpected error?

Our first PDP applications used the term "Unexpected error" as part of
the standard error routines. It meant what it said. We didn't expect a
record to go missing just after we (thought we had) read it for example.

In practice such errors were normally encountered as a result of program
bugs, but they also encompassed things like a disk going offline.

--
Paul Sture

[AEF]

On Dec 18, 2:15 am, Steven Schweda <sms.antin...@gmail.com> wrote:
> On Dec 17, 11:56 am, Alan Feldman <alanfeldma...@gmail.com> wrote:
>
> > What is an unexpected error?  [...]
>
>    Seriously?  Is this really a complicated or otherwise
> tricky concept?

I think it's partly the different points of view: from the coder and
from the user.

>
>    Here's an example of an error which I'd expect:
>
> alp $ zip31l d0:[0000000]fred.zip login.com
> zip I/O error: no such file or directory
> zip error: Could not create output file (d0:[0000000]fred.zip)

So if you expected "no such file or directory", why didn't you fix the
problem before you ran zip?

>
>    The (excessively quoted) original complaint shows an error
> which I wouldn't (and didn't) expect.  (And don't expect to
> see again, in the next Zip beta kit, and beyond.)

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.4053_x-ww_e6967989]msvcm80.dll
(deflated 69%)

In the "expected" case, something that is assumed to be there, and
needs to be there, wasn't. So you were expecting this?

To rephrase: Your code assumes something is there, but when it's not
there it is expected not to be there (the "expected error"), yet still
produces the error message.

I understand assuming it's there. I understand the need to display the
error message when it's not there. I don't see how you can assume
something is there and then expect it not to be. Sorry, I don't follow
that.

In the "unexpected" case, there was a problem with a VMS error code
and and I'd guess a record that was too long.

So you're expecting there to be something missing in the environment
but you're not expecting a strange VMS error code and/or a record
that's too long.

I don't get it. Maybe using a different word would make it more clear.
Upon further reflection, maybe "anticipated" would be more accurate.
But that would sound funny, too: Unanticipated error. Perhaps an
improvement, nonetheless.

As far as anticipating goes, is it really so far fetched to get a non-
translatable vms error code? You've never seen VMS error messages that
didn't get translated properly? Here is a rather contrived one, which
produces the same result that we sometimes see, anyway:

$ BACKUP/IMAGE DSA1: DSA2:[ASDF]
%BACKUP-F-IMGFILSPE, /IMAGE specification must have only device name
$ STAT '$STATUS'
STATUS = "%X10A380C4"
SEVERITY = 4 Hex = 00000004 Octal = 00000000004
ERRMSG = "%BACKUP-F-NOMSG, Message number 10A380C4"
$

So you've never seen error messages like this?

%BACKUP-F-NOMSG, Message number 10A380C4

I'd say this is more annoying than unexpected!

> > "I wasn't expecting an error."
>
>    I wasn't expecting an inquiry so devoid of value.  (Call

LOL!

> me an optimist.)  Time spent on specious nit-picking might be
> better spent on testing the actual code involved here.

I don't have the code, and don't have the time. (Yeah, I have the time
to write this, but debugging would certainly take longer, as I'd have
to get the code, read the code, try the code, etc. So please spare
me!)

I'm sorry, but it just comes across rather strange. It's sort of like
an "unexpected surprise"! Gee, I wasn't expecting a surprise. (^_^)

This reminds me of my favorite error message, the first one in the
error message book. This is the best candidate for an "unexpected
error" I've ever seen:

AAA, 'file-spec'

Facility: RUNOFF, DIGITAL Standard Runoff (DSR)

Explanation: This message should never be displayed.

User Action: Contact a Digital support representative.

OK, you could convince me that _this_ is an "unexpected error." On the
other hand, does the fact that the coder actually anticipated this
make it an "expected error"?

Gee, I wasn't expecting that.

>    Just a thought.

Steven, you're too much! I love it when you write comedy. Remember the
"File spec wildcard match test?" thread? You were in truly excellent
form. I'd quote a snippet or two here, but it would be out of context.
Here's the ref: http://groups.google.com/group/comp.os.vms/msg/07eaf7e5f4d7a171?dmode=source
for those interested.

Thank you, sir.

AEF

This sig should never be displayed.

[AEF]

On Dec 18, 2:15 am, Steven Schweda <sms.antin...@gmail.com> wrote:

> On Dec 17, 11:56 am, Alan Feldman <alanfeldma...@gmail.com> wrote:

[...]

>    The (excessively quoted) original complaint shows an error

My apologies for neglecting to trim.

[...]

AEF

[...sig omitted...]

[Steven Schweda]

> In the "expected" case, something that is assumed to be there, and
> needs to be there, wasn't. So you were expecting this?

Huh? In the "expected" case, the program complains about
an error made by the user. In my case, providing an invalid
input file specification. In the "unexpected" case, the
program can't read a perfectly good file, apparently because
of a problem in the program (or a shortcoming in the C
run-time I/O system). I expect the program to complain when
the user makes a mistake like that. I don't expect it to
complain about being unable to read a valid input file.

> > [...] Time spent on specious nit-picking might be

> > better spent on testing the actual code involved here.

> I don't have the code, and don't have the time. (Yeah, I have the time
> to write this, but debugging would certainly take longer, as I'd have
> to get the code, read the code, try the code, etc. So please spare
> me!)

Read it again? I didn't ask you to diagnose or fix the
problem. I believe that I've done those things. What might
be useful is to have others (even you) test the fix to verify
that it works, and doesn't wreck anything which worked before
the (so-called) fix was applied. So, "try the code" is what,
I claim, would have some actual value. (More, that is, than
rambling on about the meaning of "unexpected" in this
context.)

On the bright side, this change will probably appear in a
(relatively harmless) beta kit before Zip 3.1 is released, so
there's some chance that any new or remaining problems will
be detected before severe damage is done, but the sooner any
problems are found, the happier I'll be, and before the next
beta release would be better than after.

[Phillip Helbig---undress to reply]

In article
<efeb9dfc-8c48-44cc...@j10g2000vbe.googlegroups.com>, AEF

<spamsi...@yahoo.com> writes:

> Facility: RUNOFF, DIGITAL Standard Runoff (DSR)
>
> Explanation: This message should never be displayed.
>
> User Action: Contact a Digital support representative.

At least it says "support representative". I once so an error from an
IBM compiler which said to contact the IBM SALES [my emphasis]
representative.

As Richard Maine (someone whose posts in I can recognize as being from
him after reading only half a sentence, without looking at any headers)
in comp.lang.fortran once said, the message "internal compiler error" is
ALWAYS correct: if it's correct, it's correct; if it's not correct, then
this incorrectness is itself an error, so again it's correct.

I like to have things like

IF
blabla
ELSE IF
blabla
ELSE IF
blabla
ELSE
STOP "Can't get here."
ENDIF

Essentially all agree what success, informational and warning messages
should be. What about error or fatal error? In my own code, I like to
use error for stuff like bad input data etc which is a user error and
fatal error for stuff like an internal error (say, some numerical
routine which failed to converge); the latter would be an "unexpected
error". What about stuff like disk full? VMS tends to treat this as a
fatal error, perhaps because it isn't directly related to the program
throwing the error. I tend to think this is something the user can do
something about. :-|

Pet peeve: MOUNT/SHADOW/CONFIRM gives -F- in the perfectly normal case
that a full shadow copy is required. Typing "Y" lets the operation
continue. Continue from a fatal error with one keystroke? I would
classify this as at worst a warning.

[AEF]

On Dec 19, 12:39 am, Steven Schweda <sms.antin...@gmail.com> wrote:
> > In the "expected" case, something that is assumed to be there, and
> > needs to be there, wasn't. So you were expecting this?
>
>    Huh?  In the "expected" case, the program complains about
> an error made by the user. In my case, providing an invalid
> input file specification.

So this is an "expected error." If the error is expected, than the
program was expecting it. Therefore, the program was expecting the
user to make this error. And that means there can be only one expected
error. Any other error, or lack of error, would be unexpected.

Sorry, this is what it sounds like to me. Maybe it's the "Mr. Spock"
in me. Or perhaps we are using very different dictionaries.

 In the "unexpected" case, the
> program can't read a perfectly good file, apparently because
> of a problem in the program (or a shortcoming in the C
> run-time I/O system).  I expect the program to complain when
> the user makes a mistake like that.  I don't expect it to
> complain about being unable to read a valid input file.

But the code *can't* read it. Shouldn't the code tell you it can't
read it and say why? And if it does, which it did, what makes it
unexpected? Isn't this really an "unexpected bug"? And if so, who
cares?

I would not only expect, but hope, that the code would complain it
couldn't read the file and tell me why.

What should the code do when it can't read a valid file? How would it
know?

Would you prefer that the code display the following?

%ZIP-F-UNEXCPERR, unexpected error

Not very informative, I'm afraid. And again, how would it know?

Maybe they teach this in computer science classes. I trained to be a
physicist.

[...]

AEF

[Steven Schweda]

> So this is an "expected error." If the error is expected,
> than the program was expecting it. Therefore, the program was
> expecting the user to make this error. And that means there
> can be only one expected error. Any other error, or lack of
> error, would be unexpected.

To me, this is utter nonsense. A user can specify
different files which present different problems, for
example, a Zip archive spec might be a: 1) Non-existent
file, 2) File which the user has no permission to read, 3)
File which is not really a Zip archive, 4) Truncated or
otherwise damaged Zip archive, ... Possibilities abound.

Who said that the _program_, and not its user, expected an
error (or anything else)?

The program, whether or not it "expects" anything,
attempts to perform certain operations, and (ideally) reports
problems when it encounters them. The user might expect the
program to do what it is told to do, when that is possible.
The user might expect the program to complain when it can't
do something which is not possible. The user might _not_
expect the program to complain when it can't do something
which _is_ (or should be) possible. Please stop me when this
gets too complicated.

> But the code *can't* read it. Shouldn't the code tell you
> it can't read it and say why? And if it does, which it did,
> what makes it unexpected?

Did _you_ expect this error? The original complainer (and
I) did not.

> Isn't this really an "unexpected bug"? And if so, who
> cares?

Which bugs _are_ expected? The error message (caused by
that bug) was unexpected (by the original complainer and by
me). Who cares if there's a bug? Uh, _I_ do? Other users
might. (_You_ might be too busy to care, but I can think of
some ways in which you might free up some time for useful
pursuits.)

> Maybe they teach this in computer science classes.

I don't know. I never took one.

> I trained to be a physicist.

So did I, but it didn't turn me into a drooling idiot, or
otherwise cause me to misinterpret perfectly simple
declarative sentences with obvious meanings.

[AEF]

On Dec 20, 12:15 am, Steven Schweda <sms.antin...@gmail.com> wrote:
> > So this is an "expected error." If the error is expected,
> > than the program was expecting it. Therefore, the program was
> > expecting the user to make this error. And that means there
> > can be only one expected error. Any other error, or lack of
> > error, would be unexpected.
>
>    To me, this is utter nonsense.  A user can specify

That was my point.

> different files which present different problems, for
> example, a Zip archive spec might be a: 1) Non-existent
> file, 2) File which the user has no permission to read, 3)
> File which is not really a Zip archive, 4) Truncated or
> otherwise damaged Zip archive, ...  Possibilities abound.
>
>    Who said that the _program_, and not its user, expected an
> error (or anything else)?

1) If the user were to expect any of the above errors (1 thru 4), why
wouldn't he fix the problem before running the code? Therefore, I
assumed it must be the programmer.

2) Didn't you have a hand in writing the code? So when you talk about
expecting or not expecting an error, I assume you're talking from the
programmer's point of view.

3) One complicating factor is the fact that I have several times
encountered error messages that say, "unexpected error . . . " So I
thought there's some kind of creature called an "unexpected error."
And now this thread comes along, and doesn't exactly help matters any!
Maybe you never encountered such a creature.

There you have three reasons why.

>    The program, whether or not it "expects" anything,
> attempts to perform certain operations, and (ideally) reports
> problems when it encounters them.  The user might expect the
> program to do what it is told to do, when that is possible.
> The user might expect the program to complain when it can't
> do something which is not possible.  The user might _not_
> expect the program to complain when it can't do something
> which _is_ (or should be) possible.  Please stop me when this
> gets too complicated.

Why would the user not want the code to complain? How else will the
user know something went wrong?

> > But the code *can't* read it. Shouldn't the code tell you
> > it can't read it and say why? And if it does, which it did,
> > what makes it unexpected?
>
>    Did _you_ expect this error?  The original complainer (and
> I) did not.

If I expect that running a program will produce an error, I try to do
something about it first. So in this sense, all errors are unexpected,
in which case the whole concept becomes meaningless.

> >  Isn't this really an "unexpected bug"? And if so, who
> > cares?
>
>    Which bugs _are_ expected?  The error message (caused by

The ones you claim cause the "unexpected errors"! Never mind.

> that bug) was unexpected (by the original complainer and by
> me).  Who cares if there's a bug?  Uh, _I_ do?  Other users
> might.  (_You_ might be too busy to care, but I can think of
> some ways in which you might free up some time for useful
> pursuits.)

I meant who cares if it's an expected or unexpected bug. It's a bug
and it needs to be fixed.

> > Maybe they teach this in computer science classes.
>
>    I don't know.  I never took one.
>
> >  I trained to be a physicist.
>
>    So did I, but it didn't turn me into a drooling idiot, or
> otherwise cause me to misinterpret perfectly simple
> declarative sentences with obvious meanings.

Really? If you're going to be insulting, at least make it funny. I'm
sorry my writing skills are not the best, but I do try.

Calling it a "puzzling" error would make sense, not an "unexpected"
error.

AEF

[Steven Schweda]

On Dec 20, 8:46 pm, AEF <spamsink2...@yahoo.com> wrote:

I realize that this is pointless, but ...

> > To me, this is utter nonsense. A user can specify

> That was my point.

Your point is that you were making no sense?

> 1) If the user were to expect any of the above errors (1
> thru 4), why wouldn't he fix the problem before running the
> code? Therefore, I assumed it must be the programmer.

Huh? Why would the user expect that he was making a
typing error, or that his file was corrupted?

> 2) Didn't you have a hand in writing the code? So when you
> talk about expecting or not expecting an error, I assume
> you're talking from the programmer's point of view.

I am a user and a developer. You are a user. Of course
I'd write to you as if we were both developers. You have a
remarkable gift for non sequitur.

> 3) One complicating factor is the fact that I have several
> times encountered error messages that say, "unexpected error

> . . . " [...]

Not in any of my code.

> There you have three reasons why.

There I have three (specious) reasons why _what_?

> If I expect that running a program will produce an error, I
> try to do something about it first. So in this sense, all
> errors are unexpected, in which case the whole concept
> becomes meaningless.

Yes, if you insist on nonsensical definitions, then many
things will make no sense.

You win. This waste of time is too tiring to continue.

[AEF]

On Dec 20, 11:56 pm, Steven Schweda <sms.antin...@gmail.com> wrote:
> On Dec 20, 8:46 pm, AEF <spamsink2...@yahoo.com> wrote:
>
>    I realize that this is pointless, but ...
>
> > >    To me, this is utter nonsense.  A user can specify
> > That was my point.
>
>    Your point is that you were making no sense?

I lost the point at this point. I won't bother to try to reconstruct
this to answer it. OK.

>
> > 1) If the user were to expect any of the above errors (1
> > thru 4), why wouldn't he fix the problem before running the
> > code? Therefore, I assumed it must be the programmer.
>
>    Huh?  Why would the user expect that he was making a
> typing error, or that his file was corrupted?

Well, I didn't think of that possibility. Yeah, I don't suppose a user
would not expect to make a typing mistake at a particular time, but
you do have to assume you'd make typing mistakes _some_ of the time.

>
> > 2) Didn't you have a hand in writing the code? So when you
> > talk about expecting or not expecting an error, I assume
> > you're talking from the programmer's point of view.
>
>    I am a user and a developer.  You are a user.  Of course
> I'd write to you as if we were both developers.  You have a
> remarkable gift for non sequitur.
>
> > 3) One complicating factor is the fact that I have several
> > times encountered error messages that say, "unexpected error
> > . . . " [...]
>
>    Not in any of my code.

All right! I'm very glad to hear that. Perhaps if I had never seen one
I would have never brought this up.

>
> > There you have three reasons why.
>
>    There I have three (specious) reasons why _what_?

Because of this part you trimmed out:

" Who said that the _program_, and not its user, expected an
error (or anything else)? "

>

> > If I expect that running a program will produce an error, I
> > try to do something about it first. So in this sense, all
> > errors are unexpected, in which case the whole concept
> > becomes meaningless.
>
>    Yes, if you insist on nonsensical definitions, then many
> things will make no sense.

My point was that an error being "unexpected" was nonsensical.

>
>    You win.  This waste of time is too tiring to continue.

OK.

Looking forward to your next episode of humor.

My apologies for any misunderstanding.

AEF

[Paul Sture]

On Wed, 21 Dec 2011 18:28:55 -0800, AEF wrote:

> On Dec 20, 11:56 pm, Steven Schweda <sms.antin...@gmail.com> wrote:
>>
>>    Huh?  Why would the user expect that he was making a
>> typing error, or that his file was corrupted?
>
> Well, I didn't think of that possibility. Yeah, I don't suppose a user
> would not expect to make a typing mistake at a particular time, but you
> do have to assume you'd make typing mistakes _some_ of the time.

From the programming point of view, any invalid user input is an
*expected error* (and nowadays with web attacks must be assumed to be
potentially malicious).

An *unexpected error* from the programming point of view is usually
caused by a hardware fault or human error (disk getting full). And as
Philip Helbig pointed out with his "Shouldn't get here" example, it can
be a programming logic error.

--
Paul Sture

[Steven Schweda]

> From the programming point of view, [...]

Good luck with that argument. You're up against a fellow
who seems to believe that a car which runs out of fuel and a
car whose engine bursts into flame are essentially
equivalent. (Personally, I expect one of those events to
happen in some ordinary circumstances, but not the other.)

> An *unexpected error* from the programming point of view is
> usually caused by a hardware fault or human error (disk

> getting full). [...]

I wouldn't call a disk-full condition an unexpected error.
If a program complained about a disk-full condition when the
disk wasn't actually full, then _that_ would be unexpected.
For example, some old versions of Zip on some system types
might create a temporary archive on the wrong device or file
system (typically in the current directory, instead of in the
user-specified archive destination directory), so the user
might get a disk-full complaint about a disk which the
program shouldn't have been using. The program might put out
an accurate complaint about a condition which the program's
author anticipated, but the condition occurred only because
of a defect in the program, so an ordinary user would not
expect the error. Just as a user might not expect an error
when Zip tries to read a perfectly normal Stream or Stream_CR
file.

[VAXman-]

In article <96a586aa-0db6-462f...@t8g2000yqg.googlegroups.com>, Steven Schweda <sms.an...@gmail.com> writes:
>> From the programming point of view, [...]
>
> Good luck with that argument. You're up against a fellow
>who seems to believe that a car which runs out of fuel and a
>car whose engine bursts into flame are essentially
>equivalent. (Personally, I expect one of those events to
>happen in some ordinary circumstances, but not the other.)

Never drove a Pinto? :)


--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

[Paul Sture]

On Thu, 22 Dec 2011 06:56:50 -0800, Steven Schweda wrote:

>> From the programming point of view, [...]
>
> Good luck with that argument. You're up against a fellow
> who seems to believe that a car which runs out of fuel and a car whose
> engine bursts into flame are essentially equivalent. (Personally, I
> expect one of those events to happen in some ordinary circumstances, but
> not the other.)

:-)

>> An *unexpected error* from the programming point of view is usually
>> caused by a hardware fault or human error (disk getting full). [...]
>
> I wouldn't call a disk-full condition an unexpected error.

Yes, I should have qualified that with something like "in an order entry
application", for that is what I was thinking of when I wrote the above.

You are quite correct when applied to programs such as zip or unzip.

> If a program complained about a disk-full condition when the disk wasn't
> actually full, then _that_ would be unexpected. For example, some old
> versions of Zip on some system types might create a temporary archive on
> the wrong device or file system (typically in the current directory,
> instead of in the user-specified archive destination directory), so the
> user might get a disk-full complaint about a disk which the program
> shouldn't have been using. The program might put out an accurate
> complaint about a condition which the program's author anticipated, but
> the condition occurred only because of a defect in the program, so an
> ordinary user would not expect the error. Just as a user might not
> expect an error when Zip tries to read a perfectly normal Stream or
> Stream_CR file.

Understood. Does the VMS flavour of Zip use SYS$SCRATCH for temporary
storage? I know I've had to redirect that somewhere other than the
default with other utilities.


--
Paul Sture

[glen herrmannsfeldt]

Paul Sture <pa...@sture.ch> wrote:

(snip)

>> I wouldn't call a disk-full condition an unexpected error.

> Yes, I should have qualified that with something like "in an order entry
> application", for that is what I was thinking of when I wrote the above.

It is if someone else fills it up while you are using it.

Also, the system I post this from mounts user directories such that
they time out after some number of hours. If a program is writing
to a file at the time, it seems to get the same error as a disk full.
(That is, the write fails.)

-- glen

[Steven Schweda]

> [...] Does the VMS flavour of Zip use SYS$SCRATCH for temporary
> storage? [...]

No. So far as I know, no flavo[u]r of Zip uses the usual
temporary directory (SYS$SCRATCH, $TMPDIR, ...). Zip uses a
temporary file (on VMS, it's currently "ZIxxxxxxxx.yyyyyyyy",
where "xxxxxxxx" is the hex process ID, and "yyyyyyyy" is a
hex serial number) in the archive destination directory.
Then, if all goes well in creating the temporary archive,
it's renamed to the user-specified name. And if the rename
operation fails, Zip tries a copy, which, if it works, can be
much slower than a rename. But the whole reason for creating
the temporary archive in the same directory as the
user-specified archive destination is so that the rename
operation will work (quickly). As I said, there have been
bugs in this code, but they should all be gone now. (The
large-file testing was good at revealing these bugs. Copying
a small archive can be painless, but copying a multi-GB
archive is easy to notice.)

Older Zip versions (on VMS) didn't have the ".yyyyyyyy",
which caused problems if the victim tried to create a split
archive, which uses multiple temporary archive files.

There's also a "-b" (/TEMP_PATH) option which lets the
user specify a directory for the temporary archive(s), but,
unless there's a bug in the program (causing an unexpected
problem), I can't think of a good reason to use it.

[Phillip Helbig---undress to reply]

In article
<e1c58379-e1a6-4b1f...@v14g2000yqh.googlegroups.com>,

Steven Schweda <sms.an...@gmail.com> writes:

> Zip uses a
> temporary file (on VMS, it's currently "ZIxxxxxxxx.yyyyyyyy",
> where "xxxxxxxx" is the hex process ID, and "yyyyyyyy" is a
> hex serial number) in the archive destination directory.
> Then, if all goes well in creating the temporary archive,
> it's renamed to the user-specified name. And if the rename
> operation fails, Zip tries a copy, which, if it works, can be
> much slower than a rename. But the whole reason for creating
> the temporary archive in the same directory as the
> user-specified archive destination is so that the rename
> operation will work (quickly).

Depending on one's hardware, it might be faster to have the source and
destination on the same disk or at least on disks with direct
connections to the same machine (say, a hobbyist system with relatively
fast controllers and disk but slow ethernet) or on different disks (say,
where there is a high-speed interconnect so the more distributed the I/O
the better).

[Steven Schweda]

> Depending on one's hardware, it might be faster to have the source and
> destination on the same disk or at least on disks with direct
> connections to the same machine (say, a hobbyist system with relatively
> fast controllers and disk but slow ethernet) or on different disks (say,
> where there is a high-speed interconnect so the more distributed the I/O
> the better).

Yes, some things are faster than others, but if the user
wants the final result in a particular place, then the
program will need to write it out there, whether or not it
writes it someplace else first. It's not obvious (to me)
that it's ever faster to write the archive once to a
temporary location, then read it back, and write it out to
the final location. But you can do it if you want.

[AEF]

OK, so users errors are expected, but hardware errors and programmer
errors aren't.

OK, so if you don't expect hardware errors, why are there monitoring
programs for such things? Are these monitoring programs also
unexpected? Don't hardware errors produce error messages? Were the
people who wrote these error messages not expecting them? If not, why
did they write them?

OK, so if you don't expect programming errors (What?!), why are bug
fixes? Are bug fixes unexpected, too? Are debuggers also unexpected?

> --
> Paul Sture

AEF

[AEF]

On Dec 22, 9:56 am, Steven Schweda <sms.antin...@gmail.com> wrote:
> > From the programming point of view, [...]
>
>    Good luck with that argument.  You're up against a fellow
> who seems to believe that a car which runs out of fuel and a
> car whose engine bursts into flame are essentially
> equivalent.  (Personally, I expect one of those events to
> happen in some ordinary circumstances, but not the other.)

OK, you're using "unexpected" to mean "very unlikely". Fair enough.
But when you strand yourself by running out of gas, I don't think
you're going to say you expected it!

> > An *unexpected error* from the programming point of view is
> > usually caused by a hardware fault or human error (disk
> > getting full). [...]
>
>    I wouldn't call a disk-full condition an unexpected error.
> If a program complained about a disk-full condition when the
> disk wasn't actually full, then _that_ would be unexpected.
> For example, some old versions of Zip on some system types
> might create a temporary archive on the wrong device or file
> system (typically in the current directory, instead of in the
> user-specified archive destination directory), so the user
> might get a disk-full complaint about a disk which the
> program shouldn't have been using.  The program might put out
> an accurate complaint about a condition which the program's
> author anticipated, but the condition occurred only because
> of a defect in the program, so an ordinary user would not
> expect the error.  Just as a user might not expect an error

The ordinary user would be puzzled. This would be a puzzling error.

When I encounter errors like this, I don't say to myself, "I wasn't
expecting that." I would instead say, "Why is this happening?"

> when Zip tries to read a perfectly normal Stream or Stream_CR
> file.

Also a puzzling error. First check the file. If the file is okay,
check the code.

OK, the muon was an unexpected discovery. (At that time, Nobel
laureate I. I. Rabi famously quipped, "Who ordered that?") The
analogous case in programming would be finding that a program could do
something you weren't expecting it to!

AEF

[glen herrmannsfeldt]

AEF <spamsi...@yahoo.com> wrote:

(snip)

> OK, so users errors are expected, but hardware errors and programmer
> errors aren't.

On an IBM S/370 some years ago I had a program abend due to a
machine check exception. That is, a hardware error that the machine
knew about, and then ended my program.

> OK, so if you don't expect hardware errors, why are there monitoring
> programs for such things? Are these monitoring programs also
> unexpected? Don't hardware errors produce error messages? Were the
> people who wrote these error messages not expecting them? If not, why
> did they write them?

More rare now, but not so many years ago the hardware was
less reliable. Having the hardware check itself gave you
more confidence in the results.

> OK, so if you don't expect programming errors (What?!), why are bug
> fixes? Are bug fixes unexpected, too? Are debuggers also unexpected?

-- glen

[Phillip Helbig---undress to reply]

In article
<83073501-d7bc-46b8...@q9g2000yqe.googlegroups.com>,

> Yes, some things are faster than others, but if the user
> wants the final result in a particular place, then the
> program will need to write it out there, whether or not it
> writes it someplace else first. It's not obvious (to me)
> that it's ever faster to write the archive once to a
> temporary location, then read it back, and write it out to
> the final location. But you can do it if you want.

Right. However, in two common cases, it might not matter where the
destination is, so one can choose the fastest place. One case would be
zipping a file before transferring it over a network then deleting the
zipped file. Another case would be zipping a file to be archived then
deleting the original version.

[Steven Schweda]

> OK, you're using "unexpected" to mean "very unlikely". Fair enough.

Actually, I was using "unexpected" to describe "something
which a normal person would not reasonably expect", but this
concept seems foreign to some of us. But, as I said, I've
grown tired of trying to explain this one.

> But when you strand yourself by running out of gas, I don't think
> you're going to say you expected it!

Wrong again. I have been in a few situations where I
either did or did not run out of fuel, but I had been
watching the needle on the gauge bounce off the pin near "E"
for a while, so, while I may have been disappointed, I was
hardly surprised when the engine died. (On one memorable
occasion, at around 02:00, when I was getting pretty
desperate in my search for an open gas station in the wilds
of southern Minnesota, I was greatly relieved to spot an
illuminated Standard station in the distance. (It was a
while ago.) As I turned off the street into the station, I
put in the clutch, and the engine died, but I was still
rolling, and able to coast up to the pump.)

> The ordinary user would be puzzled. This would be a puzzling error.

Perhaps because the error was unexpected.

> When I encounter errors like this, I don't say to myself, "I wasn't
> expecting that." I would instead say, "Why is this happening?"

Luckily, what you do or don't say to yourself in such a
situation is not particularly relevant here.

> Also a puzzling error. First check the file. If the file is okay,
> check the code.

An ordinary user might not expect to have to check the

code.

> OK, the muon was an unexpected discovery. (At that time, Nobel
> laureate I. I. Rabi famously quipped, "Who ordered that?") The
> analogous case in programming would be finding that a program could do
> something you weren't expecting it to!

How about finding that a program was unable to do
something which you had (reasonably) assumed that it could
do? (To the extent that you had thought about it at all,
that is.) Like, say, Zip being unable to read a file with
Record format: Stream or Stream_CR? Some of us might call
that an unexpected error. As one of us did. And he was
generally (but, apparently, not universally) well understood.

[Paul Sture]

On Fri, 23 Dec 2011 06:15:33 +0000, glen herrmannsfeldt wrote:

> Paul Sture <pa...@sture.ch> wrote:
>
> (snip)
>>> I wouldn't call a disk-full condition an unexpected error.
>
>> Yes, I should have qualified that with something like "in an order
>> entry application", for that is what I was thinking of when I wrote the
>> above.
>
> It is if someone else fills it up while you are using it.

OK, another tack. In my order entry application I might expect that in
the normal course of events either the RMS indexed file or the database
where the data gets written has enough space preallocated that each
application writing to it doesn't have to worry about running out of
space.

An important differentiation here is whether your program can recover
from an error itself or not. I've seen reports that if MySQL runs out of
disk space, your whole database is toast anyway.

An (extreme) alternative is to test for every conceivable error in every
program and devise a recovery strategy for every single error. Good luck
with that.

> Also, the system I post this from mounts user directories such that they
> time out after some number of hours. If a program is writing to a file
> at the time, it seems to get the same error as a disk full. (That is,
> the write fails.)
>

Is that just a generic write error, or is further information available
if you probe it?

--
Paul Sture

[AEF]

On Dec 24, 9:19 am, Steven Schweda <sms.antin...@gmail.com> wrote:
> > OK, you're using "unexpected" to mean "very unlikely". Fair enough.
>
>    Actually, I was using "unexpected" to describe "something
> which a normal person would not reasonably expect", but this
> concept seems foreign to some of us.  But, as I said, I've
> grown tired of trying to explain this one.

OK.

>
> > But when you strand yourself by running out of gas, I don't think
> > you're going to say you expected it!
>
>    Wrong again.  I have been in a few situations where I
> either did or did not run out of fuel, but I had been
> watching the needle on the gauge bounce off the pin near "E"
> for a while, so, while I may have been disappointed, I was
> hardly surprised when the engine died.  (On one memorable
> occasion, at around 02:00, when I was getting pretty
> desperate in my search for an open gas station in the wilds
> of southern Minnesota, I was greatly relieved to spot an
> illuminated Standard station in the distance.  (It was a
> while ago.)  As I turned off the street into the station, I
> put in the clutch, and the engine died, but I was still
> rolling, and able to coast up to the pump.)

Good point. Touche', almost. Well, you probably were surprised that
the needle was getting near E. I assume you expected to have enough
gas to make it to your destination. So the fact that the needle
starting getting close to E would have been the surprise (unexpected),
but the consequence, running out of gas, would not, of course. Thus
the ultimate error here was expecting to have enough gas to make it to
your destination. The actual running out of gas merely an outcome, not
an error.

>
> > The ordinary user would be puzzled. This would be a puzzling error.
>
>    Perhaps because the error was unexpected.

Well, I don't see why that follows. Cannot a easy error be
"unexpected"?

> > When I encounter errors like this, I don't say to myself, "I wasn't
> > expecting that." I would instead say, "Why is this happening?"
>
>    Luckily, what you do or don't say to yourself in such a
> situation is not particularly relevant here.

Isn't "unexpected" a subjective term?

>
> > Also a puzzling error. First check the file. If the file is okay,
> > check the code.
>
>    An ordinary user might not expect to have to check the
> code.

Well, an ordinary use ought to expect to ask for help!

>
> > OK, the muon was an unexpected discovery. (At that time, Nobel
> > laureate I. I. Rabi famously quipped, "Who ordered that?") The
> > analogous case in programming would be finding that a program could do
> > something you weren't expecting it to!
>
>    How about finding that a program was unable to do
> something which you had (reasonably) assumed that it could
> do?  (To the extent that you had thought about it at all,
> that is.)  Like, say, Zip being unable to read a file with
> Record format: Stream or Stream_CR?  Some of us might call
> that an unexpected error.  As one of us did.  And he was
> generally (but, apparently, not universally) well understood.

I guess it's your point of view. I always expect errors. But then
there are "unexpected successes," in which I rejoice! Expect low, aim
high. Nothing is more disappointing than disappointment. Nothing
succeeds like success (my favorite description of "natural
selection").

AEF

[AEF]

On Dec 25, 11:29 pm, Paul Sture <p...@sture.ch> wrote:
> On Fri, 23 Dec 2011 06:15:33 +0000, glen herrmannsfeldt wrote:

> > Paul Sture <p...@sture.ch> wrote:
>
[...]

> An important differentiation here is whether your program can recover
> from an error itself or not.  I've seen reports that if MySQL runs out of
> disk space, your whole database is toast anyway.
>
> An (extreme) alternative is to test for every conceivable error in every
> program and devise a recovery strategy for every single error.  Good luck
> with that.

Well, I tried really hard to do that with my TO.COM program (a SET
DEFAULT program with lots of useful features). If anyone finds a bug,
please do tell!

[...]
> Paul Sture

AEF

[Steven Schweda]

> [...] Well, you probably were surprised that the needle was

> getting near E. I assume you expected to have enough gas to

> make it to your destination. [...]

Again, you assume too much. In some cases, I expected
_not_ to have enough fuel to get to my destination, but I
expected to find a fuel depot sooner than I did. I was very
well aware of the fuel supply as it was dwindling.

> Well, I don't see why that follows. Cannot a easy error be
> "unexpected"?

And I don't see how "puzzling" and "easy" are always
antonyms.

> Isn't "unexpected" a subjective term?

Different people may expect different things. Many
reasonable people (among whom you seem not to be) might
expect Zip to be able to handle Stream and Stream_CR files
(with long and/or unterminated) records.

You seem to have an intense personal interest in trying to
dispute the obvious. (Or what should be obvious.)

[AEF]

On Dec 27, 1:13 am, Steven Schweda <sms.antin...@gmail.com> wrote:
> > [...] Well, you probably were surprised that the needle was
> > getting near E. I assume you expected to have enough gas to
> > make it to your destination. [...]
>
>    Again, you assume too much.  In some cases, I expected
> _not_ to have enough fuel to get to my destination, but I
> expected to find a fuel depot sooner than I did.  I was very
> well aware of the fuel supply as it was dwindling.

What you seem to be saying is that an "unexpected error" is the result
of an assumption (or one assigned a, perhaps very, high probability by
the "user") gone wrong. OK. I guess I never make such assumptions
running software. This way when software actually does work, it's a
joy to behold! OK, I'm exaggerating. A lot of software works pretty
darn well.

>
> > Well, I don't see why that follows. Cannot a easy error be
> > "unexpected"?
>
>    And I don't see how "puzzling" and "easy" are always
> antonyms.

You trimmed too much, the context is lost, and I'm not going back.

>
> > Isn't "unexpected" a subjective term?
>
>    Different people may expect different things.  Many
> reasonable people (among whom you seem not to be) might
> expect Zip to be able to handle Stream and Stream_CR files
> (with long and/or unterminated) records.

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
zip warning: could not read input file:

It says the record is too large. Why should it be unexpected that
there's a limit to something? VMS has limits: 8 levels of
subdirectories, 32767 versions of a file, and isn't there a limit on
how long a record can be? EDT is limited to lines of lest than 256
records, and limited to something like 65536 records or similar. 39
chars in an ODS-2 file name or file type. All the limits in a user's
authorization record. So why not a record too long for Zip?

>    You seem to have an intense personal interest in trying to
> dispute the obvious.  (Or what should be obvious.)

Hey, it's not my fault if you can't explain it clearly.

AEF

[Steven Schweda]

> It says the record is too large. Why should it be
> unexpected that there's a limit to something?

Well, duh. The problem is not that _some_ limit exists.
The problem is that this (unexpected) limit exists.

> VMS has limits: 8 levels of subdirectories,

alp $ create /directory /log [sms.2.3.4.5.6.7.8.9.10]
%CREATE-I-CREATED, ALP$DKC0:[SMS.2.3.4.5.6.7.8.9.10] created

> 32767 versions of a file, and
> isn't there a limit on how long a record can be?

In some contexts, there may be a limit on record length.
Why should this be one of them?

> EDT is
> limited to lines of lest than 256 records, and limited to
> something like 65536 records or similar. 39 chars in an ODS-2
> file name or file type. All the limits in a user's
> authorization record. So why not a record too long for Zip?

I'll bite. Why should the same data in a file with no
record delimiters cause no trouble if it's Record format:
Stream_LF, but this problem if it's Record format: Stream or
Stream_CR?

> Hey, it's not my fault if you can't explain it clearly.

Right. A Web search for:
parker horticulture
leads to a quotation which leaps to mind here.

On second thought, forget the whole thing. You're right,
it's a complete miracle when any computer program does
anything useful, so every program failure should be expected.
I was being unforgivably obtuse to suggest otherwise.

[AEF]

On Dec 28, 1:30 am, Steven Schweda <sms.antin...@gmail.com> wrote:
> > It says the record is too large. Why should it be
> > unexpected that there's a limit to something?
>
>    Well, duh.  The problem is not that _some_ limit exists.
> The problem is that this (unexpected) limit exists.
>
> >  VMS has limits: 8 levels of subdirectories,
>
>       alp $ create /directory /log [sms.2.3.4.5.6.7.8.9.10]
>       %CREATE-I-CREATED, ALP$DKC0:[SMS.2.3.4.5.6.7.8.9.10] created

Hi Ken!

Well, duh! It wasn't always this way. My point is that it once was,
and for a long time. I was just giving an example. Yes, I should have
perhaps said VAX/VMS (!).

>
> >  32767 versions of a file, and
> > isn't there a limit on how long a record can be?
>
>    In some contexts, there may be a limit on record length.
> Why should this be one of them?

I don't know. I'm not familiar with the code.

Oh, another limit: VMS backup block sizes, and two different ones: one
on tape and a smaller one on disk! 65535 and 32767. This led Carl
Lydick to always warn people not to use block sizes higher than what
could be on disk so that copying a save set to disk wouldn't break it.
And if you exceed the limits you should expect problems!

>
> >  EDT is
> > limited to lines of lest than 256 records, and limited to
> > something like 65536 records or similar. 39 chars in an ODS-2
> > file name or file type. All the limits in a user's
> > authorization record. So why not a record too long for Zip?
>
>    I'll bite.  Why should the same data in a file with no
> record delimiters cause no trouble if it's Record format:
> Stream_LF, but this problem if it's Record format: Stream or
> Stream_CR?

A bug.

Well, the OP (the one who used the word "unexpected") did not mention
anything about Stream_LF, but perhaps I missed it. It was you who
brought it up after it was already labeled as an "unexpected error."

>
> > Hey, it's not my fault if you can't explain it clearly.
>
>    Right.  A Web search for:
>       parker horticulture
> leads to a quotation which leaps to mind here.

What's good for the goose . . . . Touche' Monsieur!

>
>    On second thought, forget the whole thing.  You're right,
> it's a complete miracle when any computer program does
> anything useful, so every program failure should be expected.
> I was being unforgivably obtuse to suggest otherwise.

I said I was exaggerating. I guess you missed that part.

OK, Ken. We simply have different views. I think part of the problem
may be the software I use every day. Outlook 2010, Windows Search in
any of it's programs. Lots of headaches every day, every hour, all the
time, due to errors of every kind. I recently upgraded Confluence from
2.9.2 to 3.5.7. Lots of problems, but it's running great now in
production. Now I'm working on JIRA 3.13.1 to 4.4.4. Lots of problems,
but I got the hard part done. Now it's just getting the easy details
and such into a procedure. MySQL was partly to blame in both cases!
Using Ctrl-F in Firefox fails in certain contexts for no discernable
reason (and now FF is telling me I misspelled discernable!). Maybe
it's time to try Chrome or Opera. And Safari doesn't even have that
functionality!

OKAY? It's just gotten to the point that if 20 minutes in my workday
goes by without an error or crash, I'm simply amazed. You, on the
other hand, must be living in a completely different software
environment. Perhaps you are lucky enough to work solely in an Alpha/
VMS world. Or we just have different points of view.

OK.

AEF

[AEF]

On Dec 28, 9:04 pm, AEF <spamsink2...@yahoo.com> wrote:
> On Dec 28, 1:30 am, Steven Schweda <sms.antin...@gmail.com> wrote:

[...]

> Oh, another limit: VMS backup block sizes, and two different ones: one
> on tape and a smaller one on disk! 65535 and 32767. This led Carl
> Lydick to always warn people not to use block sizes higher than what
> could be on disk so that copying a save set to disk wouldn't break it.
> And if you exceed the limits you should expect problems!
>

Actually I believe the limit on disk is effectively 32256.

Sorry for the goof.

AEF

[Paul Sture]

Tip. If you get brain fade and can't remember that number, give BACKUP
32000, and it will work it out itself.

I suppose there's no guarantee that this behaviour will remain in future
versions of BACKUP, but it's worked ever since I first started using
TK70s. (IIRC there was a hardware constraint with the combination of
TK50 and VAXstationn 2000 which set the limit at 16K.)


--
Paul Sture

[Bob Koehler]

In article <12ad511e-c626-4d28...@q11g2000vbq.googlegroups.com>, AEF <spamsi...@yahoo.com> writes:

> On Dec 28, 1:30=A0am, Steven Schweda <sms.antin...@gmail.com> wrote:
>> > It says the record is too large. Why should it be
>> > unexpected that there's a limit to something?
>>

>> =A0 =A0Well, duh. =A0The problem is not that _some_ limit exists.

>> The problem is that this (unexpected) limit exists.
>>

>> > =A0VMS has limits: 8 levels of subdirectories,
>>
>> =A0 =A0 =A0 alp $ create /directory /log [sms.2.3.4.5.6.7.8.9.10]
>> =A0 =A0 =A0 %CREATE-I-CREATED, ALP$DKC0:[SMS.2.3.4.5.6.7.8.9.10] created

>
> Hi Ken!
>
> Well, duh! It wasn't always this way. My point is that it once was,
> and for a long time. I was just giving an example. Yes, I should have
> perhaps said VAX/VMS (!).

No, you should have said Files-11 ODS-2 without the use of a rooted
logical.

ODS-2 is limited to 16 when a rooted logical is used, VAX, Alpha, or
Itanium. ODS-1 (VAX only) is even more limited. ODS-5 has no such
limit, although the ability of a VAX to access is is limited.

But yes, once upon a time would have been accurate.

[AEF]

I'm sure it will be close enough. As long as it doesn't go too big! I
think 32000 is pretty safe.

Thank you.

AEF

[AEF]

On Dec 31 2011, 3:32 pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:

> In article <12ad511e-c626-4d28-b71f-6321ac92a...@q11g2000vbq.googlegroups.com>, AEF <spamsink2...@yahoo.com> writes:
>
>
>
>
>
>
>
>
>
> > On Dec 28, 1:30=A0am, Steven Schweda <sms.antin...@gmail.com> wrote:
> >> > It says the record is too large. Why should it be
> >> > unexpected that there's a limit to something?
>
> >> =A0 =A0Well, duh. =A0The problem is not that _some_ limit exists.
> >> The problem is that this (unexpected) limit exists.
>
> >> > =A0VMS has limits: 8 levels of subdirectories,
>
> >> =A0 =A0 =A0 alp $ create /directory /log [sms.2.3.4.5.6.7.8.9.10]
> >> =A0 =A0 =A0 %CREATE-I-CREATED, ALP$DKC0:[SMS.2.3.4.5.6.7.8.9.10] created
>
> > Hi Ken!
>
> > Well, duh! It wasn't always this way. My point is that it once was,
> > and for a long time. I was just giving an example. Yes, I should have
> > perhaps said VAX/VMS (!).
>
>    No, you should have said Files-11 ODS-2 without the use of a rooted
>    logical.
>
>    ODS-2 is limited to 16 when a rooted logical is used, VAX, Alpha, or
>    Itanium.

Another limit!

 ODS-1 (VAX only) is even more limited.

Yet another limit!

ODS-5 has no such
>    limit, although the ability of a VAX to access is is limited.

Still yet another limit!

>
>    But yes, once upon a time would have been accurate.

OK. Thank you, Bob.

Well, the rooted logical method could cause problems with incremental
backups, no?

Still further yet another limit!

AEF

[Bob Koehler]

In article <640fc585-3ff6-4a9f...@m7g2000vbc.googlegroups.com>, AEF <spamsi...@yahoo.com> writes:
>
> Well, the rooted logical method could cause problems with incremental
> backups, no?

No. BACKUP can handle the resulting 16 levels.

[AEF]

On Jan 3, 9:26 am, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:

> In article <640fc585-3ff6-4a9f-85ce-6ba863256...@m7g2000vbc.googlegroups.com>, AEF <spamsink2...@yahoo.com> writes:
>
>
>
> > Well, the rooted logical method could cause problems with incremental
> > backups, no?
>
>    No.  BACKUP can handle the resulting 16 levels.

Well, I'm pretty sure older versions can't. I believe this capability
was added to VMS BACKUP around v6 or v6.2, but I'm not sure.

AEF

[AEF]

On Dec 28 2011, 9:04 pm, AEF <spamsink2...@yahoo.com> wrote:
> On Dec 28, 1:30 am, Steven Schweda <sms.antin...@gmail.com> wrote:
>

[...]

>
> OK, Ken. We simply have different views. I think part of the problem
> may be the software I use every day. Outlook 2010, Windows Search in
> any of it's programs. Lots of headaches every day, every hour, all the
> time, due to errors of every kind. I recently upgraded Confluence from
> 2.9.2 to 3.5.7. Lots of problems, but it's running great now in
> production. Now I'm working on JIRA 3.13.1 to 4.4.4. Lots of problems,
> but I got the hard part done. Now it's just getting the easy details
> and such into a procedure. MySQL was partly to blame in both cases!
> Using Ctrl-F in Firefox fails in certain contexts for no discernable
> reason (and now FF is telling me I misspelled discernable!). Maybe
> it's time to try Chrome or Opera. And Safari doesn't even have that
> functionality!
>
> OKAY? It's just gotten to the point that if 20 minutes in my workday
> goes by without an error or crash, I'm simply amazed. You, on the
> other hand, must be living in a completely different software
> environment. Perhaps you are lucky enough to work solely in an Alpha/
> VMS world. Or we just have different points of view.
>
> OK.
>
> AEF

Crap. I confused you (Steve Schweda) with a Ken I know. Sorry about
that. Silly me.

AEF

[AEF]

On Dec 28 2011, 9:04 pm, AEF <spamsink2...@yahoo.com> wrote:

> On Dec 28, 1:30 am, Steven Schweda <sms.antin...@gmail.com> wrote:
>

[...]

>
> OK, Ken. We simply have different views. I think part of the problem

(should be Steve)

> may be the software I use every day. Outlook 2010, Windows Search in
> any of it's programs. Lots of headaches every day, every hour, all the
> time, due to errors of every kind. I recently upgraded Confluence from
> 2.9.2 to 3.5.7. Lots of problems, but it's running great now in
> production. Now I'm working on JIRA 3.13.1 to 4.4.4. Lots of problems,
> but I got the hard part done. Now it's just getting the easy details
> and such into a procedure. MySQL was partly to blame in both cases!
> Using Ctrl-F in Firefox fails in certain contexts for no discernable
> reason (and now FF is telling me I misspelled discernable!). Maybe
> it's time to try Chrome or Opera. And Safari doesn't even have that
> functionality!
>
> OKAY? It's just gotten to the point that if 20 minutes in my workday
> goes by without an error or crash, I'm simply amazed. You, on the
> other hand, must be living in a completely different software
> environment. Perhaps you are lucky enough to work solely in an Alpha/
> VMS world. Or we just have different points of view.
>
> OK.
>
> AEF

Steve!

I really blew it this time! There is a bug in IE8 wherein if I press
Alt+Spacebar to get the System Menu, it hangs. So I tried killing that
window with Task Manager (TM), clicked "End Session", tried to move
the TM out off of the End Session box to see what happened, and got a
blank white area (a sure sign of trouble!) and my entire Windows
session hung! And I'm working from home today over VPN with RDC. Nice.
Well, I tried killing iexplore.exe from Task Manager (which is the
only thing still working) and lucked out. I don't have to reboot from
home, now!

You see now why there are no "unexpected errors" for me. A continual
stream of errors. Ah, that's life.

AEF

[Steven Schweda]

> > OK, Ken. [...]

> Crap. I confused you (Steve Schweda) with a Ken I know.
> Sorry about that. Silly me.

Don't worry about it, Barbie.

> I said I was exaggerating. I guess you missed that part.

No, I read it, but it seemed inconsistent with all the
other stuff like:

> You see now why there are no "unexpected errors" for me.

> [...]

So I followed the main stream of the (nonsensical) argument,
and ignored the anomalous (contrary, sensical) crumb embedded
therein.

[Bob Koehler]

In article <9630a4cc-2498-4f33...@z25g2000vbs.googlegroups.com>, AEF <spamsi...@yahoo.com> writes:
>
> Well, I'm pretty sure older versions can't. I believe this capability
> was added to VMS BACKUP around v6 or v6.2, but I'm not sure.

BACKUP has never failed me, going back to VMS 1.x on an 11/780. I
don't recall exactly when in there the ability to get to 16 directory
levels was implemented for ODS-2 via rooted logicals, it might have
been in some minor version that we skipped, but I don't recall a
problem or a fix. I think the ability to deal with it was added
to BACKUP before the capability to have it shipped.

I very much recall using rooted logicals with no depth problems under
VMS 5.2 through 5.5-2.

And yes, I do recall using DSC2 before BACKUP got /IMAGE.

[AEF]

On Jan 4, 9:18 am, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:

When I was in graduate school I sometimes used a VAX 11/780 located at
the Computer Science Center. They had something like the following in
their announcement banner:

Do not create directories more than six levels deep.

The used something like

define user_disk disk:[users.]

so that already accounts for one level. I bet someone got burned by
not having some really deep stuff covered by incremental backups! I
remember one guy had something like USER_DISK:
[LABYRINTH.LABYRINTH.LABYRINTH.LABYRINTH.LABYRINTH.LABYRINTH.LABYRINTH.LABYRINTH].

An incremental backup would miss stuff in the deepest directory.

Yeah, you could go 16 levels deep, but non-image BACKUP save
operations would miss levels more than 8 deep.

Yeah, we're talking old, v3 or v4.

Well, BACKUP may have never failed you back as far as v1.x, but that
depends exactly what you needed from it!

Regardless, 8 or 16, an annoying limit.

AEF

[AEF]

No worries. We just have different viewpoints.

How about this: "unexpected success". (!) (~_^)

AEF

[glen herrmannsfeldt]

AEF <spamsi...@yahoo.com> wrote:
(snip)

> When I was in graduate school I sometimes used a VAX 11/780 located at
> the Computer Science Center. They had something like the following in
> their announcement banner:

> Do not create directories more than six levels deep.

I remember in VMS 1.x renaming a directory into itself, and then
being surprised that it was accepted. Fixed not so much later.

-- glen

[Bob Koehler]

In article <je5pb6$ti1$2...@speranza.aioe.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
> I remember in VMS 1.x renaming a directory into itself, and then
> being surprised that it was accepted. Fixed not so much later.

In VMS 1.x, the pnly protection against deleting a directory was that
they were created without delete access.

VMS 2.x started checking for non-empty directories.

[AEF]

Still further even yet another limit!

$ NAME = F$ELEMENT(01,TAB,INREC)
%DCL-W-BUFOVF, command buffer overflow - shorten expression or command
line

One offending line was 1058 bytes long.

AEF

[Steven Schweda]

While reviewing the Info-ZIP Zip documentation on the way
toward the version 3.1d beta release, I noticed this note in
"TODO", which has been there since, at latest, version 2.3
(28-NOV-1999, which is as far back as my source-kit
collection goes, so actual age: unknown, but great):

--------
Known bugs:

- On VMS, zip fails reading some files with "byte record too large for
user's buffer". You must use the "-V" option for such files.
--------

With only that uselessly vague problem description to work
from, I never did any work on it. _Now_, however, it seems
likely that that note referred to the problem recently
reported here involving %rms-w-rtb or %rms-e-netbts errors on
input files having record format Stream or Stream_CR, and
long records. _That_ problem should be fixed in the next Zip
release, thanks to a more detailed problem report made in
this forum.

That's why (useful) complaints are always welcome.