开云体育

Please note: I have now had several requests but I do not have any VP/CSS materials or the actual OS. I also don't know anyone who would have access to such a thing. Folks is getting old.....

On Mon, Feb 21, 2022 at 02:48 PM, <mikeci@...> wrote:

But, I am thinking modifying dmksep to always load ucs. That way 0x9f can be used to split output into separate files.

It looks like the place you would use to print the end banner page, if you still want one.

?... Mark S.

The following files have been uploaded to the Files area of the [email protected] group.

• /WAKEUP/WAKEUP.VMARC.A.zip

By: Mark A. Stevens <marXtevens@...>

Description:
WAKEUP ASSEMBLE, SCHMAC MACLIB, extracted macros, and SCHMAC MEMO in VMARC, then zipped. vmarc list wakeup vmarc a WAKEUP ASSEMBLE A5. Bytes in= 2880, bytes out= 0 ( 0%). SCHMAC MACLIB A1. Bytes in= 30320, bytes out= 0 ( 0%). $$DOLBL MACRO A1. Bytes in= 1120, bytes out= 0 ( 0%). $$EQU MACRO A1. Bytes in= 1040, bytes out= 0 ( 0%). $$IFCX MACRO A1. Bytes in= 9120, bytes out= 0 ( 0%). $BGNDO MACRO A1. Bytes in= 1280, bytes out= 0 ( 0%). $BIT MACRO A1. Bytes in= 2160, bytes out= 0 ( 0%). $BYTE MACRO A1. Bytes in= 1200, bytes out= 0 ( 0%). $CASE MACRO A1. Bytes in= 4000, bytes out= 0 ( 0%). $CYCLE MACRO A1. Bytes in= 880, bytes out= 0 ( 0%). $DO MACRO A1. Bytes in= 6480, bytes out= 0 ( 0%). $ELSE MACRO A1. Bytes in= 1280, bytes out= 0 ( 0%). $ELSEIF MACRO A1. Bytes in= 3120, bytes out= 0 ( 0%). $ENDDO MACRO A1. Bytes in= 2000, bytes out= 0 ( 0%). $ENDIF MACRO A1. Bytes in= 1360, bytes out= 0 ( 0%). $IF MACRO A1. Bytes in= 3600, bytes out= 0 ( 0%). $NIBIT MACRO A1. Bytes in= 720, bytes out= 0 ( 0%). $OIBIT MACRO A1. Bytes in= 720, bytes out= 0 ( 0%). $TMBIT MACRO A1. Bytes in= 720, bytes out= 0 ( 0%). $UNDO MACRO A1. Bytes in= 1040, bytes out= 0 ( 0%). $XIBIT MACRO A1. Bytes in= 720, bytes out= 0 ( 0%). SCHMAC MEMO A1. Bytes in= 4720, bytes out= 0 ( 0%). Ready; T=0.05/0.07 12:15:36

On Sat, Feb 12, 2022 at 09:33 AM, Anthony Smith wrote:

MACLIB MAP tells me the SCHMAC MACLIB is not a library. I have had a look and it is full of macros that I can read by eye including the ??EQU that defines the registers. Cannot work out what could be the issue with SCHMAC other than perhaps it originates from a later VM?

Sorry for the delay. As usual life gets in the way. SCHMAC MACLIB has been regenerated under VM/370 CE V1R1.

?... Mark S

Mike wrote:

Actually, with latest hercules (Hercules version 4.4.1.10647-SDL-
gd0ccfbc9). this is what I see in the file:


00000000 9f 0d 0c 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a
|................|
00000010 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a
|................|

MUCH better! The "9f" is Hercules's translation of VM/370's X'FF' character to ASCII (which, depending on what CODEPAGE Hercules is using, gets translated to ASCII X'9F').

So, indeed there is 0x9f as first character in the file. This is
created by dmksep, and is load ucs. If one drains printer and starts
it again, 0x9f will appear again.

Which is what Dave Wade already determined earlier.

0xff was there before in those two files from my previous post.

Which I'm *guessing* might be because either: a) you were either using and older version of Hercules, or b) you were using a CODEPAGE that translates EBCDIC X'FF' to ASCII X'FF'. One or the other or both.

It also seems that there is no end banner.

As I said, I can't help you with that. But I'm sure there's probably an easy way to do it. Check with Dave Wade or Bob Bolch. They should be able to help you.

But, I am thinking modifying dmksep to always load ucs. That way
0x9f can be used to split output into separate files.

Have fun. :)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Actually, with latest hercules (Hercules version 4.4.1.10647-SDL-gd0ccfbc9). this is what I see in the file:

Mike wrote:

Great. thanks for detailed explanation. But that doesn't happen
on z/VM or VM/ESA,

I would venture a guess the reason is likely because IBM realized it wasn't actually accomplishing anything and so decided to change it.

and why do you see 4 more bytes after 0xff, but before form feed?

I don't know. None of us are seeing that. What version of Hercules are you using, and does your Hercules configuration file contain a CODEPAGE statement and does the device statement for your printer have the "crlf" or any other options specified?

It is not that you just see 0xff and form feed, but two empty lines and
then form feed.

That's expected! VM/370, as explained and shown in a previous post, is writing 0xff to the printer TWICE!

And each one will appear as a separate line whenever you view the file with a program that doesn't understand what it's looking at (because Hercules writes out either a CR or CRLF after each 0xff since it's interpreting the 0xff as print line data).

So, if you were to follow the instructions in the output
file, you would have one empty page with that strange
character printed out, followed by the rest of the output.

Correct!

Fish, how is your HercPrt handling this?

Using my HercPrt requires that your printer device statement NOT specify the "crlf" option. This ensures that lines that are printed "without spacing" are followed by Hercules with just a single CR (carriage return) character and normal (write then space) print lines are followed by one or more LF (line feed) characters. Then it's just a matter of properly dealing with the CRs and LFs that are received.

Lines are buffered and not written out until they need to be. CRs cause another "line" to be buffered in memory, and when it's eventually forced out, the buffered "lines" (overlays, however many there may be) are each printed individually, thereby allowing overstriking (overlaying) to occur (or bolding if the same character is printed multiple times or underlining if overlaid with an underline character, etc).

Remember, with HercPrt, this is being written to a PDF file, not to a text file, so displaying multiple characters on top of one another (overstriking) is a "simple" matter of writing the proper PDF code to "display this character at this position" multiple times, each time for a different character (but at the same position on the page). Underlines are dealt with the same way.

Next question would be how to add end banner in DMKBOX, or in the spooler?

I have no idea. Ask someone else.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Great. thanks for detailed explanation. But that doesn't happen on z/VM or VM/ESA, and why do you see 4 more bytes after 0xff, but before form feed? It is not that you just see 0xff and form feed, but two empty lines and then form feed. So, if you were to follow the instructions in the output file, you would have one empty page with that strange character printed out, followed by the rest of the output. Fish, how is your HercPrt handling this?

Next question would be how to add end banner in DMKBOX, or in the spooler?

Olaf wrote:

Fish wrote:

[...]

I *suppose* such logic *could* be added to Hercules so that
such unexpectedly formatted printer text files don't get created
(they would instead contain just the single "this is a test"
print line and NOT two separate "this a" and "is test" lines),
but that would seem> like an awful lot of effort to go to just
to "fix" such an (IMHO) extremely minor issue.

Also, to be proper, such a "fix" should be even more complicated:
it should not do its work when there are multiple non-space characters
printed in the same position. Those would be meant as bold, or
underlined, or even some combination of other characters...

Quite right. Dealing with overstrikes would indeed be problematic.

So, indeed totally not worth it.

Agreed.

Which is why I personally wouldn't bother trying to implement such a thing in Hercules even if someone does decide to submit such a request: it's just not worth it.

For proper overstrike handling you should use a proper post-processing product specifically designed for such things, such as my HercPrt () for example.

Does a similar product exist for the non-Windows crowd? I think there are some scripts or something out there that can create PDF files from Hercules printer output, but I'm not sure whether they can handle overstrikes.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Dave Wade wrote:

Fish wrote:

[...]

The CCW trace confirms it: it's VM/370 purposely doing it,
and it does indeed appear to be some type of printer device
initialization sequence that it's only performing when VM's
real physical printer is first started for the very first
time after an IPL.

Not true. Its possible to generate multiple "FF" characters in a
print file. It appears to be when you tell CP to START a printer,
so commence printing from the Spool. So a DRAIN and START, or a
simple START with a different class will both generate the "FF"
character in the data stream.

Okay, that makes sense I guess. So it doesn't do it the first time AFTER AN IPL, but rather EACH time it's "START"ed.

I assume this is because in between the printer could have been
attached to a VM such as DOS or MVS.

Seems like a reasonable assumption.

Thanks Dave.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

On Sat 19 Feb 2022 at 15:34:22 -0800, Fish Fish wrote:

I *suppose* such logic *could* be added to Hercules so that such
unexpectedly formatted printer text files don't get created (they
would instead contain just the single "this is a test" print line and
NOT two separate "this a" and "is test" lines), but that would seem
like an awful lot of effort to go to just to "fix" such an (IMHO)
extremely minor issue.

Also, to be proper, such a "fix" should be even more complicated: it
should not do its work when there are multiple non-space characters
printed in the same position. Those would be meant as bold, or
underlined, or even some combination of other characters...

So, indeed totally not worth it.

-Olaf.
--
___ "Buying carbon credits is a bit like a serial killer paying someone else to
\X/ have kids to make his activity cost neutral." -The BOFH falu.nl@rhialto

The CCW trace confirms it: it's VM/370 purposely doing it, and it does indeed
appear to be some type of printer device initialization sequence that it's only
performing when VM's real physical printer is first started for the very first
time after an IPL.

Not true. Its possible to generate multiple "FF" characters in a print file. It appears to be when you tell CP to START a printer, so commence printing from the Spool.
So a DRAIN and START, or a simple START with a different class will both generate the "FF" character in the data stream.
I assume this is because in between the printer could have been attached to a VM such as DOS or MVS.

Dave

Bob Bolch wrote:

I am uploading the print file and the trace log to the
"0-Temp" directory on h390-vm.

Thanks!

The CCW trace confirms it: it's VM/370 purposely doing it, and it does indeed appear to be some type of printer device initialization sequence that it's only performing when VM's real physical printer is first started for the very first time after an IPL.

The I/O it is issuing to the printer consists of a chain of three commands: two Write Without Spacing commands (opcode X'01') followed by a Sense command (opcode X'04'):


15:22:47 HHC01315I 0:000E CHAN: ccw 01A28017 60000001=>FF .
15:22:47 HHC01315I 0:000E CHAN: ccw 01A28017 60000001=>FF .
15:22:47 HHC01312I 0:000E CHAN: stat 0C00, count 0000
15:22:47 HHC01315I 0:000E CHAN: ccw 04000000 30000001
15:22:47 HHC01312I 0:000E CHAN: stat 0C00, count 0000
15:22:47 HHC01316I 0:000E CHAN: csw 00, stat 0C00, count 0000, ccw A28010


As you can see, the two Write Without Spacing commands are indeed writing a X'FF' character to the printer (why it does it twice I don't know; you'd think ONCE would be good enough!) which I'm guessing on a real 1403 would probably be treated either as a NOP (No Operation) since no such character exists on its print train, or else as causing an error (which we're not seeing in Hercules), which is then immediately followed by a Sense command to read the sense information (presumably to clear the presumed/expected Unit Check, which as I said, we're not seeing in Hercules).

The Sense command that it's issuing is interesting: it's only for one byte (rather than the full 32 bytes which is what you normally see) and it has the X'10' "Skip Data Transfer" CCW flag on too, which means no actual sense information (data) is being returned. VM appears to not be interested in the sense information at all. It appears it's only interested in clearing whatever Unit Check error might exist in the device due to its X'FF' writes.

From that point on, it behaves normally, happily printing its reports in the normal fashion: skipping to the top of a new page before printing each report, and, as mentioned earlier, simply stopping printing after the last line of the report is printed! Right in the middle of a page!(*)

So the "problem" is not really a problem at all. Both VM/370 *and* Hercules too are both behaving completely normally. They are both doing exactly what they are supposed(?) to be doing. There is actually NO "bug" to be fixed! What you are seeing is completely normal.

It just *appears* to be "unusual" from a human being point-of-view when you view the resulting print file in a text editor, that's all. The first character of the file (the X'FF' which, depending on what CODEPAGE you are using in Hercules, might or might not get translated to a different ASCII character, such as X'9F' like it did for you Bob (what CODEPAGE are you using?) but which didn't for Mike) just seems unexpected to a human being. But it's actually exactly what we would expect to happen given the circumstances: we TOLD Hercules to write the printer to a text file, so it did! It wrote *exactly* what VM/370 told it to write! It's just that text files cannot deal very well with "overlaid" print lines, that's all.

If you print the line:

this a

without spacing, followed by the line:

is test

the actual print line that you would normally see on a real 1403 printer would be:

this is a test

But when you ask Hercules to write its printer data to a text file, you end up seeing two lines, the first of which ("this a") ends with only a CR (Carriage Return) character and the second ("is test") ending with the normal/expected CRLF (Carriage Return + Line Feed) (or just LF if the "crlf" option isn't specified on your Hercules device statement).

If you use a product such as my HercPrt however, it handles "line overlaying" automatically and the report that results is exactly as you would expect: "this is a test".

But when asking Hercules to write to a text file, you end up seeing each individual "partial" print line separately, because Hercules does not contain any special logic to deal with automatically "combining" subsequent print lines with any previous print line(s) that might have been written "Without Spacing".

I *suppose* such logic *could* be added to Hercules so that such unexpectedly formatted printer text files don't get created (they would instead contain just the single "this is a test" print line and NOT two separate "this a" and "is test" lines), but that would seem like an awful lot of effort to go to just to "fix" such an (IMHO) extremely minor issue.

But hey, if someone wants to create a new GitHub Issue for it, I say go for it! Someone might actually eventually get around to doing it someday!

But it probably won't be me. ;-)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Hello!
Giving credit where it is due, those two text files were ones I
created from printer output runs from my first go round VM/370rel6,
and noted the presence of the banner. Dave W confirmed why the banner
was there. I also noticed the two characters before that banner.

Besides, whatever the reason it's beyond all of us I believe.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."

Dave Wade wrote:

[...]

Define "First Print Out".

The very first printout printed to the printer after an IPL!

VM has a "shedload" of printer and spool control command.

Understood.

So you can vary the physical printer on/offline.

Understood.

You can start, drain and stop the spooler

Understood.

Then you can change the spooler classes.

Understood.

It possible that any one of these can trigger the "FF" character.

Possibly. Possibly not. I don't know! But all I'm referring to by "first printout" is the actual very first time that VM/370's REAL printer actually PRINTS something.

Look at it this way: your Hercules printer device is defined to create a text file:

000E 1403 print00e.txt crlf

Start with a completely empty "print00e.txt" print file. Then bring up Hercules and IPL VM/370. Then print something. then examine the print file (print00e.txt). Does the file contain 0xff?

Take note of the file size (how many bytes large it is).

Then print something else (another listing). Then examine the file again (print00e.txt). Does the second listing in the print file also start with a 0xff? I suspect it won't. I suspect every listing written to the print file after the first one will start with just a normal 0x0c (i.e. ASCII form-feed character).

Then if you want, yes, you can do your other tests. You can stop the printer in VM and start it again. You can vary it offline and back online again. You can change the printer's print class, etc. You can do all of those tests too if you want. I don't care. That's your business.

I'm only interested in whether the problem occurs on subsequent printouts or only on the very first one after an IPL. Because *that* is where I suspect the bug is in VM. Yes, the bug could be elsewhere. I readily concede that point. But if, as I suspect, the problem occurs only on the very first printout after an IPL but not on subsequent printouts (after an IPL), then I feel that is probably the best place to start looking for the bug: in its "first time" logic that writes spooled listings to its real printer. THAT is the most likely place for the bug to be IMO. That's all I'm saying.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

On Sat, 19 Feb 2022 at 14:04, Dave Wade <dave.g4ugm@...> wrote:

BOTTOM LINE: The mystery lies with VM/370, not Hercules.

So I loaded up a basic VM/370 built a long time ago from the starter system and it does it. So no modification, no added software, just as it came from the release tape.
It puts the 0xFF on the first print file. So its been there since the mists of time.

Except that without looking at the EBCDIC<->ASCII table in use, it may
not have been a X'FF' that VM cranked out.

Tony H.

Mike wrote:

Yes, I am sure about 0xff. As a matter of fact, ...

<snip>

Have you tried doing a CCW trace yet?

After powering on Hercules, BEFORE you IPL VM/370, enter the command "t+00e" (or whatever the device address is for your printer). Then once VM/370 comes up, print something. Then print something else. (The smaller the better of course).

Then shutdown and exit Hercules and send me (or temporarily upload to the group's Files area) the resulting Hercules log file.

Thanks.

p.s. What's your printer device statement look like in your Hercules configuration file?

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Dave Wade wrote:

Fish wrote:

[...]

I would suggest taking a close look at VM/370's spooler logic.
I'm sure you'll find the bug there somewhere. A bug which was
likely fixed in later versions
of VM.

Well VM/SP still does it. I suspect its intended behaviour.
If I finish my Spanish homework I will have a look.

Before you (or Bob? or anyone else) does so however, you should first confirm whether or not it, as I suspect it might, only occurs on the very first printout or not, or whether it always occurs on every printout.

If it always occurs, then I can accept that it's expected behavior. If it only occurs on the very first printout however, then it's IMO probably a bug.

Either that or maybe it's (VM/370) trying to send some type of unusual undocumented CCW command code/data to the printer that Hercules isn't expecting. Maybe some type of special undocumented "reset" command perhaps?

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...