I've been playing with printing messages to the console log using wto to see how many characters fit on one line, autowrapping, & use of newlines. I've noticed some quirks while playing with the newline.
In this example, below I just printed one super long string & which then wraps as expected.
start0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789end
However, in this second example I introduce newlines after "start" & after the message before "end".
After, the first newline after "start" there is a sequence of numbers, "075" in the example below, which increment as I print again & again. What is this sequence? Why is there this sequence there but not after the 2nd line before "end"?
The second quirk I noticed was that the 2nd line, the message doesn't print the entire screen length before wrapping like in the above example, but prematurely stops & then wraps.
start 075 (1st line ends)
0123456789012345678901234567890123456789012345678901234567890123456789 (2nd line wrap)
012345678901234567890123456789 (2nd line ends)
end (3rd line)
Thanks
wto printing quirks...anyone know why?
Well,
technically the original MVS macro has a limit of 120 chars per line.
Though, certain rules apply to multi-line console messages.
Usually, to avoid that complexity most traditional MVS programmer limit their printing to the console to individual lines varying between 80 to 120 chars.
Since, I’m assuming the jZos classes are wrappers around C/C++ function call __console2() , that restriction may apply as well.
technically the original MVS macro has a limit of 120 chars per line.
Though, certain rules apply to multi-line console messages.
Usually, to avoid that complexity most traditional MVS programmer limit their printing to the console to individual lines varying between 80 to 120 chars.
Since, I’m assuming the jZos classes are wrappers around C/C++ function call __console2() , that restriction may apply as well.