kerravon86@yahoo.com.au [hercules-390]
2017-04-23 05:27:10 UTC
In my JES2PARM on MVS I have this:
&NOPRCCW=30 PRINTER CCW LIMIT
When my program writes to SYSOUT=*
with DCB of VBA (not VB), what I am
seeing is that every 30 lines a blank line
is emitted.
Here is what it looks like (note that I
start at line 0):
line 26
line 27
line 28
line 29
line 30
line 31
line 32
line 33
line 34
line 35
line 36
line 37
line 38
line 39
line 40
line 41
line 42
line 43
line 44
line 45
line 46
line 47
line 48
line 49
line 50
line 51
line 52
line 53
line 54
line 55
line 56
line 57
line 58
line 59
line 60
Those blank lines actually look like this:
025320 4154494F 4E20434F 44452049 53202020 ATION CODE IS
025330 20202020 2020302E 0D0A0D0D 0C0A6C69 0.......li
025340 6E652030 0D0A6C69 6E652031 0D0A6C69 ne 0..line 1..li
025350 6E652032 0D0A6C69 6E652033 0D0A6C69 ne 2..line 3..li
025360 6E652034 0D0A6C69 6E652035 0D0A6C69 ne 4..line 5..li
025370 6E652036 0D0A6C69 6E652037 0D0A6C69 ne 6..line 7..li
025380 6E652038 0D0A6C69 6E652039 0D0A6C69 ne 8..line 9..li
025390 6E652031 300D0A6C 696E6520 31310D0A ne 10..line 11..
0253A0 6C696E65 2031320D 0A6C696E 65203133 line 12..line 13
0253B0 0D0A6C69 6E652031 340D0A6C 696E6520 ..line 14..line
0253C0 31350D0A 6C696E65 2031360D 0A6C696E 15..line 16..lin
0253D0 65203137 0D0A6C69 6E652031 380D0A6C e 17..line 18..l
0253E0 696E6520 31390D0A 6C696E65 2032300D ine 19..line 20.
0253F0 0A6C696E 65203231 0D0A6C69 6E652032 .line 21..line 2
025400 320D0A6C 696E6520 32330D0A 6C696E65 2..line 23..line
025410 2032340D 0A6C696E 65203235 0D0A6C69 24..line 25..li
025420 6E652032 360D0A6C 696E6520 32370D0A ne 26..line 27..
025430 6C696E65 2032380D 0D0A6C69 6E652032 line 28...line 2
025440 390D0A6C 696E6520 33300D0A 6C696E65 9..line 30..line
ie here:
025430 6C696E65 2032380D 0D0A6C69 6E652032 line 28...line 2
you have 0D 0D 0A
As far as I am aware, that is considered
to be a corrupt text file under Windows.
Line endings are meant to be 0D0A and
the above sequence will instead produce
random results depending on your
editor. This leads to many lively discussions
about whether a text file has blank lines
in it or not, as both sides use their trusted
editor and insist that they do/don't exist.
As such, under no circumstance should
Hercules be generating such a corrupt
file.
The reason this happens is diagnosed here:
http://www.jaymoseley.com/hercules/faq/mvsfaq02.htm
JES2 sends a CCW of x'01', write without advancing, which Hercules interprets by sending a single carriage return character to the print file (x'0d'). When JES2 begins processing the next block, it sends a CCW of x'0b', space once immediately, which Hercules interprets by sending a carriage return/line feed pair to the print file (x'0d'x'0a'). So the print file contains the sequence x'0d'x'0d'x'0a'
The Hercules 3.12 source code printer.c
has this:
/* changed to */
/* search the fcb array starting at the CURRENT line position */
/* check if the previous operation was a write no space */
#define SKIP_TO_CHAN() \
suggesting that there is logic in there
to handle this situation.
However, I have tested with the following
versions of standard Hercules:
3.07 fails
3.08 fails
3.09 fails
3.10 fails
3.11 fails
3.12 fails
4.00 rc0 fails
and they all produce the corrupt file.
I think the fix should be for CCW x'01'
to do nothing. After all, in an output
text file, nothing is actually required.
If data is printed without a terminating
0d0a (Windows) or 0a (Unix), so what?
Surely that is exactly correct?
Regardless, when the next CCW comes
through, the "imperfect" (but not corrupt)
file above suddenly because 100% fixed,
so who cares?
So did someone expect that this problem
had already been fixed? If so, it hasn't.
The printer code changed radically between
3.07 and 3.08. If someone would like to
debug this problem on 3.08 printer.c, I can
assist in doing tests. Otherwise, the fix
in Hercules/380 3.07 is very simple. I'm
just going to change this bit of code in
printer.c:
case 0x01:
/*---------------------------------------------------------------*/
/* WRITE WITHOUT SPACING */
/*---------------------------------------------------------------*/
eor = "\r";
goto write;
to:
eor = "";
Note that I originally discovered the
problem under TSO batch where
SYSTSPRT apparently has a default
of VBA. If I override the DCB to VB
the problem goes away.
Thanks. Paul.
&NOPRCCW=30 PRINTER CCW LIMIT
When my program writes to SYSOUT=*
with DCB of VBA (not VB), what I am
seeing is that every 30 lines a blank line
is emitted.
Here is what it looks like (note that I
start at line 0):
line 26
line 27
line 28
line 29
line 30
line 31
line 32
line 33
line 34
line 35
line 36
line 37
line 38
line 39
line 40
line 41
line 42
line 43
line 44
line 45
line 46
line 47
line 48
line 49
line 50
line 51
line 52
line 53
line 54
line 55
line 56
line 57
line 58
line 59
line 60
Those blank lines actually look like this:
025320 4154494F 4E20434F 44452049 53202020 ATION CODE IS
025330 20202020 2020302E 0D0A0D0D 0C0A6C69 0.......li
025340 6E652030 0D0A6C69 6E652031 0D0A6C69 ne 0..line 1..li
025350 6E652032 0D0A6C69 6E652033 0D0A6C69 ne 2..line 3..li
025360 6E652034 0D0A6C69 6E652035 0D0A6C69 ne 4..line 5..li
025370 6E652036 0D0A6C69 6E652037 0D0A6C69 ne 6..line 7..li
025380 6E652038 0D0A6C69 6E652039 0D0A6C69 ne 8..line 9..li
025390 6E652031 300D0A6C 696E6520 31310D0A ne 10..line 11..
0253A0 6C696E65 2031320D 0A6C696E 65203133 line 12..line 13
0253B0 0D0A6C69 6E652031 340D0A6C 696E6520 ..line 14..line
0253C0 31350D0A 6C696E65 2031360D 0A6C696E 15..line 16..lin
0253D0 65203137 0D0A6C69 6E652031 380D0A6C e 17..line 18..l
0253E0 696E6520 31390D0A 6C696E65 2032300D ine 19..line 20.
0253F0 0A6C696E 65203231 0D0A6C69 6E652032 .line 21..line 2
025400 320D0A6C 696E6520 32330D0A 6C696E65 2..line 23..line
025410 2032340D 0A6C696E 65203235 0D0A6C69 24..line 25..li
025420 6E652032 360D0A6C 696E6520 32370D0A ne 26..line 27..
025430 6C696E65 2032380D 0D0A6C69 6E652032 line 28...line 2
025440 390D0A6C 696E6520 33300D0A 6C696E65 9..line 30..line
ie here:
025430 6C696E65 2032380D 0D0A6C69 6E652032 line 28...line 2
you have 0D 0D 0A
As far as I am aware, that is considered
to be a corrupt text file under Windows.
Line endings are meant to be 0D0A and
the above sequence will instead produce
random results depending on your
editor. This leads to many lively discussions
about whether a text file has blank lines
in it or not, as both sides use their trusted
editor and insist that they do/don't exist.
As such, under no circumstance should
Hercules be generating such a corrupt
file.
The reason this happens is diagnosed here:
http://www.jaymoseley.com/hercules/faq/mvsfaq02.htm
JES2 sends a CCW of x'01', write without advancing, which Hercules interprets by sending a single carriage return character to the print file (x'0d'). When JES2 begins processing the next block, it sends a CCW of x'0b', space once immediately, which Hercules interprets by sending a carriage return/line feed pair to the print file (x'0d'x'0a'). So the print file contains the sequence x'0d'x'0d'x'0a'
The Hercules 3.12 source code printer.c
has this:
/* changed to */
/* search the fcb array starting at the CURRENT line position */
/* check if the previous operation was a write no space */
#define SKIP_TO_CHAN() \
suggesting that there is logic in there
to handle this situation.
However, I have tested with the following
versions of standard Hercules:
3.07 fails
3.08 fails
3.09 fails
3.10 fails
3.11 fails
3.12 fails
4.00 rc0 fails
and they all produce the corrupt file.
I think the fix should be for CCW x'01'
to do nothing. After all, in an output
text file, nothing is actually required.
If data is printed without a terminating
0d0a (Windows) or 0a (Unix), so what?
Surely that is exactly correct?
Regardless, when the next CCW comes
through, the "imperfect" (but not corrupt)
file above suddenly because 100% fixed,
so who cares?
So did someone expect that this problem
had already been fixed? If so, it hasn't.
The printer code changed radically between
3.07 and 3.08. If someone would like to
debug this problem on 3.08 printer.c, I can
assist in doing tests. Otherwise, the fix
in Hercules/380 3.07 is very simple. I'm
just going to change this bit of code in
printer.c:
case 0x01:
/*---------------------------------------------------------------*/
/* WRITE WITHOUT SPACING */
/*---------------------------------------------------------------*/
eor = "\r";
goto write;
to:
eor = "";
Note that I originally discovered the
problem under TSO batch where
SYSTSPRT apparently has a default
of VBA. If I override the DCB to VB
the problem goes away.
Thanks. Paul.