Rene, Thanks, I know I should have looked. I hope you can’t hear me scream. So I also need to fix CMSCMDS and CPCMDS as both don’t match what is installed….. There is more paul stuff such as DIFF, DIFF3, CPYFILE?? yuk yuk yuk. I think we need a cheat sheet on how to add a command and what needs updating…. Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of René Ferland
Sent: 03 January 2022 15:11
To: [email protected]
Subject: Re: [h390-vm] CLOAD EXEC? According to HELP CMSCMDS:
CLOAD? ?Load a C program (compiled with GCCE) into memory.
so Paul Edwards stuff.? :-)
Cheers,
Rene FERLAND, Montreal
|
Folks, I seem to have found a quirk in the EE editor, or perhaps the “C” run time it depends on. If I edit an existing file. E.g. ? EE TEST FILE A ? Or ? EE TEST FILE ? The filemode is set to “A1” even if the existing file is “A2”. I haven’t investigated the run time… .. it makes creating helpfiles a minor chore… ? Dave
|
According to HELP CMSCMDS:
CLOAD? ?Load a C program (compiled with GCCE) into memory.
so Paul Edwards stuff.? :-)
Cheers,
Rene FERLAND, Montreal
|
Folks, Does any one know what the “CLOAD” exec on the “Y” disk is for, or from whence it came. Dave
|
Re: Using Hercules version specific config file parameters with VM370CE
Hi Bob, Fish and others,
Please note that I'm including information provided by Fish is a
newer post than this one...
To summarize the posts and include additional information to the
discussion.
??? Hercules 3.x knows nothing about the newer Hercules 4.x
ARCHLVL and other configuration parameters.
??? Hercules 4.x will accept the older Hercules 3.x configuration
parameters, but will issue a warning that are deprecated.
??? Fish's HercGUI (Windows only) currently rejects the Hercules
3.x configurations parameters (to be accepted in the next release)
and INCLUDE statements.
??? Jacob Dekel's HercStudio (Linux and Mac) only supports
Hercules 3.x only.? I'm not sure if it accepts INCLUDE
statements.?
??? ??? I'm not sure that Jacob is maintaining this as the Yahoo
group is no longer available.
??? None graphical interface users who are only affected by the
differences between Hercules 3.x and 4.x.
I had thought that Bob's option 3 was the best and easiest to
maintain, but given the above information, I would suggest a
single file with both Herc 3.x and Herc 4.x statements commented
out and include some sort of Installation/User document similar to
Jurgen Winkelmann's TK4- document.?
Fish has suggested an configuration/installation script to make
the necessary changes to the configuration file based on the
version of Hercules installed or failing that to prompt the user
for the Hercules version.?
I think that a good Installation/User manual would go a long way
to making new users to VM/370 CE more comfortable and at ease with
it no matter which Hercules version or direction is chosen by the
maintainers.
As far as dropping support for older versions of Hercules, I
would say not until there is a reliable way to get SDL Hercules
4.x installed on Linux and Mac either by the distro's Software
Manager utility, a DEB/RPM file or a reliable Build/Make file from
source option.? Otherwise, you will have done a disservice to the
community.
Thanks for listening.
Regards,
Gary?
On 1/2/22 10:58 AM, Bob Bolch wrote:
toggle quoted message
Show quoted text
I changed the subject line to be more specific.
I caused the existing difficulty with ARCHLVL -vs-
ARCHMODE because I thought that 3.13 supported both. That
was an error on my part. However, there are more
incompatibilities than just ARCHMODE/ARCHLVL.? The currently
available VM370CE release exposed bugs in ECPSVM support for
Hyperion only. That bug is reported as fixed, but I have
found new bugs in the operation of the CP PER command
modification, when ECPSVM YES is present in the
configuration file and Hyperion 4.4.0 is used.
I think saying that you cannot use VM370CE with HERCGUI
is not desirable, when the change needed to allow that
package to work is trivial for the end user.?
Which of these is the most acceptable?for VM370CE to
supply?
1. A config file for each release.?
2. One config file with tailoring instructions for other
releases.
3. A small config file for each release. Each has an
INCLUDE statement to pull in the common elements. Most
statements are common between releases and would be in this
common section.
4. One config file for the oldest supported Hercules
release with instructions for modifying it for other
Hercules releases.?
5. Same as 4, but we supply one config file for the
newest release.
A separate question is can we ever drop support for a
Hercules release??
Another question is what happens when an "old"
configuration statement like ARCHMODE stops being accepted
by a newer Hercules?
Your thoughts would be appreciated.
Bob Bolch
|
Re: Using Hercules version specific config file parameters with VM370CE
A very good new year to all of us, and thank you for this exemplary and very positive discussion.
A separate question is can we ever drop support for a Hercules release?
A *damn* good question!
My point of view is this: although our efforts are focused on preservation of our heritage, this is only part of it, it is not a museum(1), and recent releases of OS and VM from the community contain clear anachronisms - which I am very happy about!
I am not inclined to regard the simulator a part of this museum, and I would love it to move forward. In my view, when end of support for a specific application, like the VM/370CE set, is *clearly indicated*, well in advance, *and* a version that is compatible with older versions *is kept online* (with an optional, do-it-yourself upgrade path).
The version indication can be of the form ‘VM/370CE VxRyMz is tested with release X of Hercules, and issues can be filed for releases upwards of version Y only; lower versions are not supported by the maintainers’.
I deplore the forking that took place but let’s not open that wound. In my opinion, the introduction of an incompatibility, for instance in the Hercules parameters, must have a very good reason. This is why I am particularly happy with Fish’s and Bobs latest email exchange.
Let me finish with: we, the users and maybe only occasional developers are very thankful for all your work on this, and look at VM/370CE, how very nice it has become with the xedit and rexx compatible, well working contributions on it.
best regards,
搁别苍é.
(1) well maybe the ideal museum, in which you can play with everything, everything works, and keeps getting better.
|
Re: Using Hercules version specific config file parameters with VM370CE
Bob Bolch wrote: I changed the subject line to be more specific.
I caused the existing difficulty with ARCHLVL -vs- ARCHMODE
because I thought that 3.13 supported both. And I compounded the difficulty by coding my HercGUI to summarily reject ARCHMODE (even though Hercules v4.x still accepts it (albeit with a deprecation warning)). That was an error on my part. And on my part as well. However, there are more incompatibilities than just
ARCHMODE/ARCHLVL. Indeed. New statements have been added and old ones changed or dropped altogether. The currently available VM370CE release exposed bugs in ECPSVM
support for Hyperion only. That bug is reported as fixed, but I
have found new bugs in the operation of the CP PER command
modification, when ECPSVM YES is present in the configuration
file and Hyperion 4.4.0 is used. Uh oh! I hope you opened a new github issue for this so we (you?) can get it fixed! I think saying that you cannot use VM370CE with HERCGUI is not
desirable, when the change needed to allow that package to work
is trivial for the end user. True. But what we *really* need is a foolproof(?) way of detecting which version of Hercules the user intends to use, and then using the correct (compatible) configuration file for that version. Which of these is the most acceptable for VM370CE to supply?
1. A config file for each release. Yes. With each clearly marked as being for what version, and separate invoking scripts for each version (e.g. "hercv3 ..." and "hercv4 ..."). Each would be identical except for which configuration file it used. OR... perhaps some sophisticated batch file logic that determines ahead of time which version of Hercules the user has installed (is going to use) and then setting a flag telling it which config file to use. But I agree something needs to be done. 2. One config file with tailoring instructions for other releases.
3. A small config file for each release. Each has an INCLUDE statement to
pull in the common elements. Most statements are common between releases
and would be in this common section. That would work for Hercules since Hercules does indeed support INCLUDE statements. Unfortunately however, my HercGUI doesn't (yet). :( 4. One config file for the oldest supported Hercules release with
instructions for modifying it for other Hercules releases.
5. Same as 4, but we supply one config file for the newest release. Between 4 and 5, I prefer 5 of course, but then I'm biased too. A separate question is can we ever drop support for a Hercules release? A *damn* good question! Another question is what happens when an "old" configuration statement
like ARCHMODE stops being accepted by a newer Hercules? Another good question. Your thoughts would be appreciated. Done. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: Change to http://vm370.org/VM/V1R1.1
Dave Wade wrote: There is no need for two configs. The 6-pack was not designed
to work with the FISH GUI and it only fails with the FISH GUI.
A tweak to the fish GUI config allows it to works. FYI: It was a mistake on my part for HercGUI to always reject ARCHMODE. I apologize for the grief/confusion it has caused the community. Since Hercules v4.x still accepts ARCHMODE in addition to ARCHLVL (albeit with a deprecated warning message), the upcoming "soon to be released" new version of HercGUI now does too. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Using Hercules version specific config file parameters with VM370CE
I changed the subject line to be more specific.
I caused the existing difficulty with ARCHLVL -vs- ARCHMODE because I thought that 3.13 supported both. That was an error on my part. However, there are more incompatibilities than just ARCHMODE/ARCHLVL.? The currently available VM370CE release exposed bugs in ECPSVM support for Hyperion only. That bug is reported as fixed, but I have found new bugs in the operation of the CP PER command modification, when ECPSVM YES is present in the configuration file and Hyperion 4.4.0 is used.
I think saying that you cannot use VM370CE with HERCGUI is not desirable, when the change needed to allow that package to work is trivial for the end user.?
Which of these is the most acceptable?for VM370CE to supply?
1. A config file for each release.? 2. One config file with tailoring instructions for other releases. 3. A small config file for each release. Each has an INCLUDE statement to pull in the common elements. Most statements are common between releases and would be in this common section. 4. One config file for the oldest supported Hercules release with instructions for modifying it for other Hercules releases.? 5. Same as 4, but we supply one config file for the newest release.
A separate question is can we ever drop support for a Hercules release??
Another question is what happens when an "old" configuration statement like ARCHMODE stops being accepted by a newer Hercules?
Your thoughts would be appreciated. Bob Bolch
|
Re: Change to http://vm370.org/VM/V1R1.1
Joe, There is no need for two configs. The 6-pack was not designed to work with the FISH GUI and it only fails with the FISH GUI. A tweak to the fish GUI config allows it to works. Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Joe Monk
Sent: 02 January 2022 15:12
To: [email protected]
Subject: Re: [h390-vm] Change to http://vm370.org/VM/V1R1.1? Dave, Maybe you should deliver two versions of the config file... One specifically for v4 (ARCHLVL) and one that is "general" (ARCHMODE). Or deliver one file with #ARCHMODE and tell the user to uncomment it and comment ARCHLVL... ? Ant, ? The old version works with both 3.13 and 4.xx. The change to the new version was made because the FISH GUI objects to the old version. I believe the real fix is to tell people we don’t support using it with the FISH GUI and/or they need to tell the FISH GUI not to check the config. ? Dave ? ? I have devised several ways of automagically stepping over the issue that I bumped into running CE with 3.13. but using the KISS principle, perhaps a clearer statement on point 3 on this web page would be a good first/only step needed. It needs to clearly state that 3.13 will NOT work with CE unless you modify the config.?
Alternatively, I don't know what happens if you simply put both statements into the config file, as I don't have Hyperion to check. It is OK with 3.13.
Ant
|
Re: Change to http://vm370.org/VM/V1R1.1
Dave,
Maybe you should deliver two versions of the config file... One specifically for v4 (ARCHLVL) and one that is "general" (ARCHMODE).
Or deliver one file with #ARCHMODE and tell the user to uncomment it and comment ARCHLVL...
Joe
Ant, ? The old version works with both 3.13 and 4.xx. The change to the new version was made because the FISH GUI objects to the old version. I believe the real fix is to tell people we don’t support using it with the FISH GUI and/or they need to tell the FISH GUI not to check the config. ? Dave ? ? I have devised several ways of automagically stepping over the issue that I bumped into running CE with 3.13. but using the KISS principle, perhaps a clearer statement on point 3 on this web page would be a good first/only step needed. It needs to clearly state that 3.13 will NOT work with CE unless you modify the config.?
Alternatively, I don't know what happens if you simply put both statements into the config file, as I don't have Hyperion to check. It is OK with 3.13.
Ant
|
Re: Change to http://vm370.org/VM/V1R1.1
OK, perhaps "bigger" conversations are way above my "newbie" pay grade. Don't want to repeat what has already been decided. I make these comments as an innocent. I would limit them to the change to those about item 3 on the web page.
|
|
|
Problems with the LOG file
Gentles, You get an empty log file with Hercules. I have raised and issue with a solution. ?
? Dave G4UGM
|
Re: Change to http://vm370.org/VM/V1R1.1
Ant, ? The old version works with both 3.13 and 4.xx. The change to the new version was made because the FISH GUI objects to the old version. I believe the real fix is to tell people we don’t support using it with the FISH GUI and/or they need to tell the FISH GUI not to check the config. ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Anthony Smith
Sent: 02 January 2022 12:15
To: [email protected]
Subject: [h390-vm] Change to http://vm370.org/VM/V1R1.1? I have devised several ways of automagically stepping over the issue that I bumped into running CE with 3.13. but using the KISS principle, perhaps a clearer statement on point 3 on this web page would be a good first/only step needed. It needs to clearly state that 3.13 will NOT work with CE unless you modify the config.?
Alternatively, I don't know what happens if you simply put both statements into the config file, as I don't have Hyperion to check. It is OK with 3.13.
Ant
|
Change to http://vm370.org/VM/V1R1.1
I have devised several ways of automagically stepping over the issue that I bumped into running CE with 3.13. but using the KISS principle, perhaps a clearer statement on point 3 on this web page would be a good first/only step needed. It needs to clearly state that 3.13 will NOT work with CE unless you modify the config.?
Alternatively, I don't know what happens if you simply put both statements into the config file, as I don't have Hyperion to check. It is OK with 3.13.
Ant
|
Any old time VP/CSS folks out there
Understand this is off topic (admin pls bump if not OK). While playing with R1.V1.1 and simultaneously reading my VP/CSS command guide, I wondered if anyone else in the group used VP/CSS (derived from CP/67 like all good operating systems are)? Eventually I ran VM under VP to enable a conversion, and then overnight the deed was done.
|
Im going to move this over to the hercules-390 main group.
Joe
>Oh and one other thing... New Macs are ARM based. No more Intel. Also, no more 32-bit anything. Everything MAC is now 64-bit only. > >So to build for macOS, you have to build for both ARM and Intel, a least for a little while.
BTDT, back when Apple went from PPC to Intel. Building a fat binary isn't hard, but it does take some preparation to make sure all libraries you use are fat as well. And Hercules has been 64-bit clean since I made it run on the Alpha back before the turn of the century....though that didn't take a lot of work; Roger's original code was pretty portable to begin with. (And to the extent Hercules isn't that portable?today, I consider it a bug.)
|
Re: Rexx PARSE on VM/SP 5 behaves different from BRexx on VM/370 CE V1M1R1.1.
#VMCE
On Fri, Dec 31, 2021 at 08:45 PM, Bob Bolch wrote:
This is the issue we talked about a few weeks ago on this list. The BREXX interpreter has a design flaw in the PARSE statement processor. I opened an issue on the developer's website. BREXX PARSE does not process literals ( and a few other positioning arguments) in the parse template properly.?
I missed that conversation. Sorry. Thanks for the update!?... Mark S.
|
>Oh and one other thing... New Macs are ARM based. No more Intel. Also, no more 32-bit anything. Everything MAC is now 64-bit only. > >So to build for macOS, you have to build for both ARM and Intel, a least for a little while.
BTDT, back when Apple went from PPC to Intel. Building a fat binary isn't hard, but it does take some preparation to make sure all libraries you use are fat as well. And Hercules has been 64-bit clean since I made it run on the Alpha back before the turn of the century....though that didn't take a lot of work; Roger's original code was pretty portable to begin with. (And to the extent Hercules isn't that portable?today, I consider it a bug.)
|
René Ferland
Anthony Smith
Mark A. Stevens