Keyboard Shortcuts
Likes
- H390-Vm
- Messages
Search
Re: A question about vm/370 print output
#VMCE
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. |
File /WAKEUP/WAKEUP.VMARC.A.zip uploaded
#file-notice
[email protected] Notification
The following files have been uploaded to the Files area of the [email protected] group. By: Mark A. Stevens <marXtevens@...> Description: |
Re: WAKEUP - does a emulation of this module exist
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 |
Re: A question about vm/370 print output
#VMCE
Mike wrote:
Actually, with latest hercules (Hercules version 4.4.1.10647-SDL-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 isWhich 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 wayHave fun. :) -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
Re: A question about vm/370 print output
#VMCE
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? |................|
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. 0xff was there before in those two files from my previous post. It also seems that there is no end banner. But, I am thinking modifying dmksep to always load ucs. That way 0x9f can be used to split output into separate files. |
Re: A question about vm/370 print output
#VMCE
Mike wrote:
Great. thanks for detailed explanation. But that doesn't happenI 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 andThat'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 outputCorrect! 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@... |
Re: A question about vm/370 print output
#VMCE
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? |
Re: A question about vm/370 print output
#VMCE
Olaf wrote:
Fish wrote:[...] Quite right. Dealing with overstrikes would indeed be problematic.I *suppose* such logic *could* be added to Hercules so thatAlso, to be proper, such a "fix" should be even more complicated: 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@... |
Re: A question about vm/370 print output
#VMCE
Dave Wade wrote:
Fish wrote:[...] 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.The CCW trace confirms it: it's VM/370 purposely doing it,Not true. Its possible to generate multiple "FF" characters in a I assume this is because in between the printer could have beenSeems like a reasonable assumption. Thanks Dave. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
Re: A question about vm/370 print output
#VMCE
On Sat 19 Feb 2022 at 15:34:22 -0800, Fish Fish wrote:
I *suppose* such logic *could* be added to Hercules so that suchAlso, 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 |
Re: A question about vm/370 print output
#VMCE
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 |
Re: A question about vm/370 print output
#VMCE
Bob Bolch wrote:
I am uploading the print file and the trace log to theThanks! 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@... |
Re: A question about vm/370 print output
#VMCE
Hello!
toggle quoted message
Show quoted text
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." On Sat, Feb 19, 2022 at 10:50 AM <mikeci@...> wrote:
|
Re: A question about vm/370 print output
#VMCE
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 spoolerUnderstood. 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@... |
Re: A question about vm/370 print output
#VMCE
I am uploading the print file and the trace log to the "0-Temp" directory on h390-vm. Bob On Sat, Feb 19, 2022 at 3:42 PM Dave Wade <dave.g4ugm@...> wrote:
|
Re: A question about vm/370 print output
#VMCE
toggle quoted message
Show quoted text
-----Original Message-----Define "First Print Out". VM has a "shedload" of printer and spool control command. So you can vary the physical printer on/offline. You can start, drain and stop the spooler Then you can change the spooler classes. It possible that any one of these can trigger the "FF" character. Either that or maybe it's (VM/370) trying to send some type of unusualCould be any one of the above... --Dave |
Re: A question about vm/370 print output
#VMCE
On Sat, 19 Feb 2022 at 14:04, Dave Wade <dave.g4ugm@...> wrote:
Except that without looking at the EBCDIC<->ASCII table in use, it maySo 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. not have been a X'FF' that VM cranked out. Tony H. |
Re: A question about vm/370 print output
#VMCE
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@... |
Re: A question about vm/370 print output
#VMCE
Dave Wade wrote:
Fish wrote:[...] 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.I would suggest taking a close look at VM/370's spooler logic.Well VM/SP still does it. I suspect its intended behaviour. 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@... |