Be aware that the compiler is built using programming Interfaces from recent versions of VM/370 under Hercules. That may disallow the use of CMS features which came along later (for example, the extended CMS file system that allows files with more than 64k records).

The modernized CMS runtime for BREXX has updated versions of the GCS runtime code on the GCCCMS user ID. The newer runtime is on the MAINTC ID within a disk search order setup using the GCCSRCH exec on that user ID.

Bob Bolch

On Fri, Mar 4, 2022 at 01:51 PM, René Ferland wrote:

Just uploaded them!

It is file GCC-VMARC.zip. :-)

Rene FERLAND, Montreal

On Fri, Mar 4, 2022 at 12:51 PM, rvjansen@... wrote:

Yes, VMARCs in the file area would be dandy!

Just uploaded them!

Rene FERLAND, Montreal

开云体育

Yes, VMARCs in the file area would be dandy!

开云体育

The VMARC files would be great, thank you! (and some instructions, of course). I'm a long time MVS guy but I have a few years supporting VM and z/VM as well. You can send them to me directly at dstone21@..., or if someone else might want them too, I guess they could go in the files area.

Thanks!
Dennis

On Fri, Mar 4, 2022 at 08:50 AM, Dennis Stone wrote:

Does anyone have a pre-packaged setup of GCCCMS?

I took the GCCCMS of VM/370 and made three VMARC with it: one for the binaries, and two for the MACLIBs and include files (PDPCLIB or CMSLIB). I copy the whole thing on the account I have on z/VM 6.4 and that seems to work (although I just test Hello, World). Would these VMARC be okay for you? Or you would like to assemble GCCCMS from scratch?

Rene FERLAND, Montreal

This may have been asked before, but I am looking to install GCCCMS on a modern z/VM system. Does anyone have a pre-packaged setup of GCCCMS? I have downloaded the files from the GCCCMS directory in the files area, but it looks like the installation instructions are mainly for VM/370. Thanks in advance.

Dennis Stone

Waaaaay back in the early 80s on our CMS system I played a submarine warfare game while waiting on long runs to finish.

I want to say the game was "subwar" but I'm not sure. You played a sub with a finite number of torpedos, being pursued by some number of destroyers. It was decidedly low tech and very addictive.

I've been looking for the game on and off and have never found a mention. I just checked CBTTAPE.

Ring any bells?

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