hercules generating corrupt printer files

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

hercules generating corrupt printer files

Hercules390 - General mailing list
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hercules generating corrupt printer files

Hercules390 - General mailing list
 > When my program writes to SYSOUT=* with DCB of VBA (not VB), what I
 > am

 > 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.

 > 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'

Don't be an idiot.  Write without advancing is used for e.g. overstrike
(most commonly, underlining).  The only sane way to translate that from
IBM style unit record to a stream of ascii is the way Herc is doing it.
Otherwise you end up with a long line instead of an overstruck one.

De
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hercules generating corrupt printer files

Hercules390 - General mailing list
As Dennis said, simply ignoring CR may be cause problems. My guess is this exists because mechanical print trains were slow so a CR would make sense while waiting for the next buffer. The correct solution would be to do a /n instead of /r/n when the previous character was a /r.
On a real printer /r/r/n print the same as /r/n. The file is not actually corrupt because it contains exactly what a real printer would receive. On z/OS, we can save print files directly to datasets so this is not a problem.
Jon.
On Sunday, April 23, 2017 11:16 AM, "Dennis Boone [hidden email] [hercules-390]" <[hidden email]> wrote:

 

      > When my program writes to SYSOUT=* with DCB of VBA (not VB), what I
 > am

> 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.

> 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'

Don't be an idiot. Write without advancing is used for e.g. overstrike
(most commonly, underlining). The only sane way to translate that from
IBM style unit record to a stream of ascii is the way Herc is doing it.
Otherwise you end up with a long line instead of an overstruck one.

De
  #yiv0429477478 #yiv0429477478 -- #yiv0429477478ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0429477478 #yiv0429477478ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0429477478 #yiv0429477478ygrp-mkp #yiv0429477478hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv0429477478 #yiv0429477478ygrp-mkp #yiv0429477478ads {margin-bottom:10px;}#yiv0429477478 #yiv0429477478ygrp-mkp .yiv0429477478ad {padding:0 0;}#yiv0429477478 #yiv0429477478ygrp-mkp .yiv0429477478ad p {margin:0;}#yiv0429477478 #yiv0429477478ygrp-mkp .yiv0429477478ad a {color:#0000ff;text-decoration:none;}#yiv0429477478 #yiv0429477478ygrp-sponsor #yiv0429477478ygrp-lc {font-family:Arial;}#yiv0429477478 #yiv0429477478ygrp-sponsor #yiv0429477478ygrp-lc #yiv0429477478hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0429477478 #yiv0429477478ygrp-sponsor #yiv0429477478ygrp-lc .yiv0429477478ad {margin-bottom:10px;padding:0 0;}#yiv0429477478 #yiv0429477478actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0429477478 #yiv0429477478activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0429477478 #yiv0429477478activity span {font-weight:700;}#yiv0429477478 #yiv0429477478activity span:first-child {text-transform:uppercase;}#yiv0429477478 #yiv0429477478activity span a {color:#5085b6;text-decoration:none;}#yiv0429477478 #yiv0429477478activity span span {color:#ff7900;}#yiv0429477478 #yiv0429477478activity span .yiv0429477478underline {text-decoration:underline;}#yiv0429477478 .yiv0429477478attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv0429477478 .yiv0429477478attach div a {text-decoration:none;}#yiv0429477478 .yiv0429477478attach img {border:none;padding-right:5px;}#yiv0429477478 .yiv0429477478attach label {display:block;margin-bottom:5px;}#yiv0429477478 .yiv0429477478attach label a {text-decoration:none;}#yiv0429477478 blockquote {margin:0 0 0 4px;}#yiv0429477478 .yiv0429477478bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv0429477478 .yiv0429477478bold a {text-decoration:none;}#yiv0429477478 dd.yiv0429477478last p a {font-family:Verdana;font-weight:700;}#yiv0429477478 dd.yiv0429477478last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0429477478 dd.yiv0429477478last p span.yiv0429477478yshortcuts {margin-right:0;}#yiv0429477478 div.yiv0429477478attach-table div div a {text-decoration:none;}#yiv0429477478 div.yiv0429477478attach-table {width:400px;}#yiv0429477478 div.yiv0429477478file-title a, #yiv0429477478 div.yiv0429477478file-title a:active, #yiv0429477478 div.yiv0429477478file-title a:hover, #yiv0429477478 div.yiv0429477478file-title a:visited {text-decoration:none;}#yiv0429477478 div.yiv0429477478photo-title a, #yiv0429477478 div.yiv0429477478photo-title a:active, #yiv0429477478 div.yiv0429477478photo-title a:hover, #yiv0429477478 div.yiv0429477478photo-title a:visited {text-decoration:none;}#yiv0429477478 div#yiv0429477478ygrp-mlmsg #yiv0429477478ygrp-msg p a span.yiv0429477478yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv0429477478 .yiv0429477478green {color:#628c2a;}#yiv0429477478 .yiv0429477478MsoNormal {margin:0 0 0 0;}#yiv0429477478 o {font-size:0;}#yiv0429477478 #yiv0429477478photos div {float:left;width:72px;}#yiv0429477478 #yiv0429477478photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv0429477478 #yiv0429477478photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv0429477478 #yiv0429477478reco-category {font-size:77%;}#yiv0429477478 #yiv0429477478reco-desc {font-size:77%;}#yiv0429477478 .yiv0429477478replbq {margin:4px;}#yiv0429477478 #yiv0429477478ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv0429477478 #yiv0429477478ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv0429477478 #yiv0429477478ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv0429477478 #yiv0429477478ygrp-mlmsg select, #yiv0429477478 input, #yiv0429477478 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv0429477478 #yiv0429477478ygrp-mlmsg pre, #yiv0429477478 code {font:115% monospace;}#yiv0429477478 #yiv0429477478ygrp-mlmsg * {line-height:1.22em;}#yiv0429477478 #yiv0429477478ygrp-mlmsg #yiv0429477478logo {padding-bottom:10px;}#yiv0429477478 #yiv0429477478ygrp-msg p a {font-family:Verdana;}#yiv0429477478 #yiv0429477478ygrp-msg p#yiv0429477478attach-count span {color:#1E66AE;font-weight:700;}#yiv0429477478 #yiv0429477478ygrp-reco #yiv0429477478reco-head {color:#ff7900;font-weight:700;}#yiv0429477478 #yiv0429477478ygrp-reco {margin-bottom:20px;padding:0px;}#yiv0429477478 #yiv0429477478ygrp-sponsor #yiv0429477478ov li a {font-size:130%;text-decoration:none;}#yiv0429477478 #yiv0429477478ygrp-sponsor #yiv0429477478ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv0429477478 #yiv0429477478ygrp-sponsor #yiv0429477478ov ul {margin:0;padding:0 0 0 8px;}#yiv0429477478 #yiv0429477478ygrp-text {font-family:Georgia;}#yiv0429477478 #yiv0429477478ygrp-text p {margin:0 0 1em 0;}#yiv0429477478 #yiv0429477478ygrp-text tt {font-size:120%;}#yiv0429477478 #yiv0429477478ygrp-vital ul li:last-child {border-right:none !important;}#yiv0429477478

   
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: hercules generating corrupt printer files

Hercules390 - General mailing list
As some of you may know, I have been involved with the text editor SPFLite for some time.  I helped design a number of features to assist Hercules users.
 

 One of them is support for text files having spurious CR characters.  This can occur either in old-format Mac text files, or in files intending to implement overprinting, as is done in Hercules.  Here, "spurious" means either text like "data CR data" or "data CR CR LF data".
 

 If your main goal is to view or edit files with such spurious CR's, you can define a file type in SPFLite that has a PROFILE entry of EOL AUTO.  When this is done, the extra CR codes are properly handled.  If your files are actually trying to overprint something, a best-effort merging of characters is attempted.  For instance, if the overprint attempt was trying to make the line-printer equivalent of "bold", there would be the same character in the same position being printed twice.  SPFLite detects this as a 'benign' overprint, and simply takes the character once.  Any combination of blank and nonblank takes the nonblank.  Any other combination just takes the first nonblank character.  At that point, the editor will display the resulting data.
 

 For most purposes, this strategy works pretty well.  If you wanted to actually print this file, the data produced by Hercules should correct print (at least on Windows) as is, by just piping it to the printer.
 

 See www.SPFLite.com http://www.SPFLite.com for more information.

Loading...