As I've noted before, I've got a small number of fixes to contribute to the community, independent of the work I've been doing on bREXX. I've signed out update numbers for them for CP and CMS on the wiki. I've renumbered them accordingly, written small MEMO files to go with them, and I've now got a VMARC file for each update. So, now what do I do with them? Is there a central collection point I should upload them to? Is there some place I should leave a breadcrumb for the next VM/CE release? Am I just worrying too much about this? Is this all there is to life? ( 😏 ) Ross

What's a good source for the Windows binary file of the vma.exe (VMARC extractor for WIndows or Ubuntu Linux)? I found some source files, but I don't have a full Windows dev environment except for Cygwin, and it says it's missing a WXWidgets package. Some of the sites pointing at vma.exe are now gone or have malware advertising that puts up fake virus warnings. Bob Rodriguez

As part of the bREXX update effort, I sat down and wrote a full set of HELP files for it, similar to the existing set of HELPEXC for EXEC. What's the best way to distribute these? I could certainly add them to the bREXX release packages, but they'd still need to be moved to the MAINT 19D disk somehow. Or would folks rather I get them into the HELP collection at https://github.com/s390guy/vm370, from whence I expect they'd wind up in the next VM/CE release? Or other ideas? Thanks, Ross

I love that somebody added support in the CP DISPLAY command for base registers (e.g., #CP DISPLAY 8.10;BASE12 to display 16 bytes starting at 8 bytes past wherever R12 points). But the CP PER command also uses ";" to separate commands in its CMD option, and I really wanted to use them together, which makes PER think its got multiple commands when I use a ;BASE value (e.g., #CP PER I R E000.20 CMD D T0.20;BASE11). So I whipped up a small change to DMKPEC to add a "SEP char" option to PER, to specify a replacement for the command-separator character (e.g., #CP PER I R E000.20 SEP $ CMD D T0.20;BASE11). The default command-separator character is obviously ";". I can package this up for the next VM/370 release if others would find it useful. The only odd part is that DMKPEC already uses literally every byte of temporary storage it has, so to parse the PER command, I used my favorite hack for temporary work areas - the CPU fixed logout area, location X'100' in the PSA. It works, and the code doesn't expect it to survive beyond the end of command parsing, so it's fine, it's just a little weird. Ross

The following items have been added to the Files area of the h390-vm@groups.io group. /hrc432ds.vmarc By: Ross Patterson <ross.patterson@...> Description: HRC432DS EXECIO fixes. See https://github.com/s390guy/vm370/issues/95 and https://github.com/s390guy/vm370/issues/101. The following items have been added to the Files area of the h390-vm@groups.io group. /hrc405ds.vmarc By: Ross Patterson <ross.patterson@...> Description: HRC405DS NUCEXT and SUBCOM macros and functions.

The following items have been added to the Files area of the h390-vm@groups.io group. /hrc120ds.vmarc By: Ross Patterson <ross.patterson@...> Description: HRC120DS ZAP command reports DMS210E on files dated 20xx. See https://github.com/s390guy/vm370/issues/105

The following items have been added to the Files area of the h390-vm@groups.io group. /hrc080dk.vmarc By: Ross Patterson <ross.patterson@...> Description: HRC080DK Do not execute ECPS:VM assist DISP1 with PER active. See https://github.com/s390guy/vm370/issues/66

The third beta release of bREXX v1.1.0 for CMS on VM/370 is now available at https://github.com/RossPatterson/CMS-370-BREXX/releases/download/v1.1.0-beta-03/BREXX.zip. I have been testing this update for about 1 week. It has 1 additional known bug (Issue #93), which has been reproduced with bREXX 1.0.1 on VM/370 CE 1.1.2. That bug will be addressed separately from the 1.1.0 release. I do not recommend replacing your existing bREXX version with this, but it is ready for testing as the expected release candidate. The installation instructions are unchanged from the first beta email, except for the release version number, and are reproduced below. This the final beta before the actual release. My plan is to rechristen beta-03 as the final release in January, with no changes except to address any bugs that may be reported before then. Your feedback is greatly desired :-) Ross =========================== Release contents This release builds upon the existing work of others (i.e., bREXX 1.0.1), and adds: - Raise Rexx level to 3.45. I0095 - SIGNAL ON isn't turned off after trapping. I0094 - Implement NUMERIC FORM VALUE. I0092 - Add support for CONDITION(). As I noted in October and November, beta-01 and beta-02 previously added: - Add HELPREXX files. I0087 - Add support for DATE(BASEDATE). I0081 - STORAGE() built-in function incorrectly expects a decimal address. VM/SP says hex - Add support for OPTIONS instruction. I0085 - Fix TRACE N output and support TRACE F. I0080 - SIGNAL doesn't set SIGL - Fix PARSE "with literals" (vm370 Issue 61), including adding tests for PARSE instruction I0078 - Make PARSE VERSION result conform to ANSI and TRL2 standards I0075 - Implement SIGNAL ON FAILURE (Issue 75) I0073 - Fix SIGNAL ON ERROR for positive return codes (Issue 73) - Enable tests in builds and fix them to work. Some tests failed on bREXX 1.0.1 and still fail on bREXX 1.1.0 Beta: - DATE - ERRORTEXT #2 - PARSE #16, #19 - Repair and improve builder scripts Notes There are 2 breaking changes in bREXX 1.1.0. PARSE now works correctly, as noted in (vm370 Issue 61). STORAGE(address[,length]) now expects the address parameter to be a string of hexadecimal characters (e.g., "Say Storage('E000', 20)"). If you have a program uses STORAGE() with a decimal address, and you don't want to change it, you can execute an "OPTIONS STORAGE_DECIMAL" statement at any time prior to calling STORAGE(), and the address will be processed exactly as it was in bREXX 1.0.1. The known, pre-existing bugs are: Issue 89: TRACE OFF in interactive trace before PROCEDURE raises ERROR 17.1 "PROCEDURE is valid only when it is the first instruction executed after an internal CALL or function invocation" Issue 90: Calling a function that doesn't exist aborts Rexx with the error message "DLMALLOC PANIC LINE 3503" Issue 91: SIGNAL VALUE varname raises ERROR 16.1 'Label "var_value" not found', even though the label exists. Issue 93: CALL ON is just a synonym for SIGNAL ON All the prerequisites were shipped in VM/370 Community Edition v1.1.2 or earlier. I have not attempted to run it on an older CMS than that, but any system with at least the following will probably work: GCCLIB v1.0.1 HRC402DS - Support execution of REXX as filetype EXEC HRC404DS - NUCEXT and SUBCOM support HRC408DS - CMS support for REXX external function callsCMS Rexx function call support HRC412DS - PE HRC309DS. Bad EPLIST built when no cmd operands fix to EPLIST support (HRC309DS) HRC417DS - Support RDTERM TYPE=DIRECT for REXX tracing These instructions assume you're testing bREXX on the CMSUSER user, but you can use any general purpose user you prefer. DO NOT use the MAINT or MAINTC users for this purpose, as it will delete the existing bREXX files. This release includes a new tool, BRXLOAD EXEC, to load the source and object files and put them where they belong in a user structured like MAINTC. I would appreciate feedback on it, as it's very new. To install from source See also Adrian Sutherland's installation instructions. 1. Download bREXX 1.1.0-Beta 03 from the URL above to the machine where you run

Hi forum and Merry Christmas! I've stumbled with some cached web contents that, apparently, may indicate that Zork ran on CMS under VM/370. Sure, I've taken that with a grain of salt... I've that would be indeed possible, sure someone would have done that before me. As soon as I tried to give it a shot, I've found that I need the PIPE command in order to 'reblock' the actual files, but net even PIPE command seems to be available. Any clues? has anyone really made Zork run under VM/370? Thanks, Cheers. -- Alejandro Olivan. Spain.

Does anybody know where the GCCCSECT MODULE on the VM/370 CE 1.1.2 Y-disk came from? It's a C program, but I can't find any source for it, and Google has never heard of it. There's a similar program called NAMCSECT on the GCC for CMS mdisks, but it's not the same one. I'm trying to diagnose a possible bug in it, that occasionally causes bREXX compilation to fail. I'm pretty sure the problem isn't in GCC itself, but rather in this code that GCC EXEC invokes. Thanks, Ross

The second beta release of bREXX v1.1.0 for CMS on VM/370 is now available at https://github.com/RossPatterson/CMS-370-BREXX/releases/download/v1.1.0-beta-02/BREXX.zip. I have been testing this update for several weeks. It has 3 known bugs, which have all been reproduced with BREXX 1.0.1 on VM/370 CE 1.1.2. Those bugs will be addressed separately from the beta. I do not recommend replacing your existing bREXX version with it, but it is ready for broader testing. The installation instructions are unchanged from the first beta email, except for the release version number, and are reproduced below. Of special note, there are now HELP files for every Rexx instruction and built-in function. You'll find them in an archive of their own, BRXHELP VMARC, embedded in the source archive, BREXXSRC VMARC (or on its AWSTAPE equivalent). You can dump them straight onto the CMS help disk (usually MAINT 19D), or they should work just fine from any other accessed disk. There may be a beta-03 before the actual release, but with luck, nothing more. My plan is to rechristen either beta-02 or beta-03 as the final release in January. Your feedback is greatly desired :-) Fair warning: I'll be off the grid for a few weeks starting tomorrow. I'll look into any issues you may encounter when I return. Ross =========================== Release contents This release builds upon the existing work of others (i.e., bREXX 1.0.1), and adds: - Repair and improve builder scripts I0080 - SIGNAL doesn't set SIGL I0085 - Fix TRACE N output and support TRACE F. - Add support for OPTIONS instruction. I0081 - STORAGE() built-in function incorrectly expects a decimal address. VM/SP says hex I0087 - Add support for DATE(BASEDATE). - Add HELPREXX files. As I noted in October, beta-01 previously added: I0073 - Fix SIGNAL ON ERROR for positive return codes (Issue 73) I0075 - Implement SIGNAL ON FAILURE (Issue 75) I0078 - Make PARSE VERSION result conform to ANSI and TRL2 standards - Fix PARSE "with literals" (vm370 Issue 61), including adding tests for PARSE instruction - Enable tests in builds and fix them to work. Some tests failed on bREXX 1.0.1 and still fail on bREXX 1.1.0 Beta: - DATE - ERRORTEXT #2 - PARSE #16, #19 Notes * There are 2 breaking changes in bREXX 1.1.0: * PARSE now works correctly, as noted in (vm370 Issue 61) https://github.com/s390guy/vm370/issues/61 * STORAGE(address[,length]) now expects the address parameter to be a string of hexadecimal characters (e.g., "Say Storage('E000', 20)"). If you have a program uses STORAGE() with a decimal address, and you don't want to change it, you can execute an "OPTIONS STORAGE_DECIMAL" statement at any time prior to calling STORAGE(), and the address will be processed exactly as it was in bREXX 1.0.1. * The known, pre-existing bugs are: * Issue 89: TRACE OFF in interactive trace before PROCEDURE raises ERROR 17.1 "PROCEDURE is valid only when it is the first instruction executed after an internal CALL or function invocation" * Issue 90: Calling a function that doesn't exist aborts Rexx with the error message "DLMALLOC PANIC LINE 3503" * Issue 91: SIGNAL VALUE varname raises ERROR 16.1 'Label "var_value" not found', even though the label exists. * All the prerequisites were shipped in VM/370 Community Edition v1.1.2 or earlier. I have not attempted to run it on an older CMS than that, but any system with at least the following will probably work: * GCCLIB v1.0.1 * HRC402DS - Support execution of REXX as filetype EXEC * HRC404DS - NUCEXT and SUBCOM support * HRC408DS - CMS support for REXX external function callsCMS Rexx function call support * HRC412DS - PE HRC309DS. Bad EPLIST built when no cmd operandsfix to EPLIST support (HRC309DS) * HRC417DS - Support RDTERM TYPE=DIRECT for REXX tracing * These instructions assume you're testing bREXX on the CMSUSER user, but you can use any general purpose user you prefer. DO NOT use the MAINT or MAINTC users for this purpose, as it will delete the existing bREXX files. * This release includes a new tool, BRXLOAD EXEC, to load the source and object files and put them where

The wiki page Reserved CP Modification Numbers has been updated by Ross Patterson <ross.patterson@...>. Compare Revisions

The wiki page Reserved CMS Modification Numbers has been updated by Ross Patterson <ross.patterson@...>. Compare Revisions

I've just updated GitHub VM/370 issue #118 with the results of my work to create a Rexx system-level function package for the various VM/370 R6s. I have specifically tested it with both bREXX 1.0.1 (as shipped in VM/370 CE 1.1) and the first beta of bREXX 1.1.0 (as I announced last month). In combination with a small change to the bREXX DATE() function (to add BASEDATE), this brings bREXX fully up to the Rexx 3.40 level (with considerable additional function from higher levels). This package provides the DIAG() and DIAGRC() functions that VM/SP (and later) had, with the exception of C8 and CC (because VM/370 CP doesn't have those DIAGnoses). I intend to package this for inclusion in the next release of VM/370 CE, but it should work on any VM/370 system that can already run bREXX 1.0.1. If you want to use it before that, or with another VM/370 system, you can download the ZIPped VMARC file from the GitHub issue. It contains the full source and MODULE, including a few CMS macro changes that were necessary (and which are teed up for the next VM/370 CE release). Ross

Best guess is different memory size of the guest VM or saved segment layout. You ought to be able to able to run PER to get an idea of what’s causing the fault but it’s been way too many years since I’ve done that and I don’t remember the syntax.

Hi, When I was at T.I. I wrote a program to connect two virtual machines running CMS to each other using virtual CTCA. I'm wondering is it possible to have 1) Two Hercules systems on the same Windows system running VM and 2) Connect these two CMS users on each VM system via a CTCA between these two Hercules systems? Also: Is it possible to have these two VM and Hercules systems on different physical Windows or Linux systems connected by a CTCA? If so, how? What should I read? Thank you, Bertram / WB8ERT.

The wiki page Reserved CMS Modification Numbers has been updated by William Denton <williamedenton@...>. Compare Revisions

Beloved Members, Sorry to impose upon your day of rest and relaxation, but subsequent to the discussion on Modification Numbers, and prompted by todays note on DMKGRF I am reminded that most developers felt changing modification numbers was a BAD idea, and would like to be able to reserve numbers for your modifications in advance. So to assist in this I have created some pages in the Wiki https://groups.io/g/h390-vm/wiki as :- Reserved CMS Modification Numbers and Reserved CP Modification Numbers where you can reserve numbers. If there are any clashes please let me know. Dave G4UGM

I am using XEDIT and its clones since VM/SP Release 1 up to today ... and counting. EE is great work by Dr. Hans-Walter Latz, but I miss a lot of features that XEDIT and KEDIT have. I have done massive extensions to EE to make it more XEDIT-compatible. A common infrastructure already exists for the SET / QUERY / EXTRACT / MODIFY / TRANSFER subcommands. Actually I am researching how EE could integrate with bREXX. Having a macro capability powered by REXX is my first wish. The ingredients for the ALL macro will follow (SET SELECT, SET DISPLAY ...). Do you think it is desirable and feasable to have a decent subset of XEDIT as part of VM/370 CE ?

z/VM 4.4 CMS level 20 service 301 Why after TERM CONMODE 3270 i get DMSCIT171T ?