On 10 Feb 2020, at 13:49, adriansutherland67 <adrian@...> wrote:

On Mon, Feb 10, 2020 at 11:14 AM, adriansutherland67 wrote:

docker run --rm -d -p 3270:3270 -p 8038:8038 -p 3505:3505 --name vm370 adriansutherland/vm370:1.3.5

Fast start - Use from the normal windows console:

* start the container
docker run -d -p 3270:3270 -p 8038:8038 -p 3505:3505 --name vm370 adriansutherland/vm370:1.3.5

* attach to the linux console
docker exec -it vm370 /bin/bash

This will give you a linux command line, then:

herccontrol "ipl 141"

c3270 localhost:3270

(on my windows computer the mouse even works - which surprised me)
(and ctrl-c clears the 3270 screen)

Use the menu to exit c3270
then "exit" to close the shell.
And - yes you can do multiple shells via docker attach

* To stop (pause) the container
docker stop vm370

* To kill it (pull the plug)
docker kill vm370

* to unpause/start it
docker start vm370

* And to remove and delete the container
docker rm vm370

Boom!

In this config use the hercules webconsole (or herccontrol); hercules is running detached.

If your data/time becomes completely unsynced you need to restart docker desktop (and therefore stop/start your container); defect with Docker and Hybernate.

You know - its a bit like CP ...

On 11 Feb 2020, at 11:18, Dave Wade <dave.g4ugm@...> wrote:

I can't check today. What should happen is RESLIB should patch the command table..?

Dave

On Tue, 11 Feb 2020, 9:53 am?rvjansen@..., <rvjansen@...> wrote:

Hi Dave,

that is good to know. Question then is, why does the MKBREXX EXEC build a BREXX MODULE. I still cannot build the BREXX TEXT.
Just to verify: when I mount brexx 191 as J, and run MKBREXX, the .TEXT modules go to my A disk. Is that correct? Or do they need to go to J? This is what MKBREXX assumes.
Do I need to link brexx 191 in a different way? What happens when you run it?

best regards,

On 11 Feb 2020, at 10:22, Dave Wade <dave.g4ugm@...> wrote:

Folks (especially Rene)

There is no REXX MODULE because having a REXX module in CMS is pretty useless.
In VM/370 CMS MODULES are usually loaded at the same location in main store, in the start of the user area.
So if you build REXX as a module whenever it calls a program that runs in the user area it overwrites REXX.
RESLIB loads REXX at the top of storage and reserves the storage with a system flag.
You can't easily build a module to do that as they load absolute (in R6 at least) and you don't know how big some ones VM is when you build the module.

Dave

p.s. yes I know some modules run in the transient space, but it doesn't help. It just makes things worse.

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 20:15
To: [email protected]
Subject: Re: [h390-vm] building BREXX

One piece of the puzzle is this:

There is no DMSREX module in VM/370. René Ferland confirmed this.

The RESLIB command is used to load BREXX TEXT into resident storage.
RESLIB itself is not documented in the official VM/370 documents, I just read
the System Programmer’s guide and the CMS Commands and Macros guide.
It is documented by HELP RESLIB, and was written by Andrew Hanushevsky,
Langmuir Laboratory, Cornell University in 1980.

The HELP RESLIB (MORE command states that every program that is loaded in
this way, needs to be serially reusable (which is one step above/below
reentrant/reenterable, depending on how you see it). This means BREXX
may not have compiler initialized static variables. I wonder if GCC has an
option to make sure it does not, and I would be more at ease if it was
reentrant.

The loading is done for each VM/user by an exec called SYSPROF EXEC. I
found out by doing a RESLIB DELETE GCCLIB, RESLIB DELETE DMSREX for my
MAINT user, and trying to make it work again afterwards. It did not, because
the botched builds left a wrong SYSPROF EXEC on MAINT’s A disk, or that is
what I think.

As soon as I found this, and deleted the one on the A disk, the one on the V
disk is executed at logon and the info is correct again. Interestingly, the
modules GCCLIB and DMSREXX are loaded at different (virtual) address in
different userid’s. Then I remembered that the release notes for Sixpack 1.2
say:

? During initialization, CMS executes "SYSPROF EXEC" before
executing "PROFILE EXEC". This allows you to ensure certain commands are
always executed for users.


These commands are the RESLIB commands for BREXX; it then chains
SYSPROX EXEC for the mecaff programs.

I’ll keep you posted on more progress, for example whe I find out how the
exec processor finds it is a REXX exec, which is rather anachronistic for this
level of VM.

best regards,

René Jansen.

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 20:15
To: [email protected]
Subject: Re: [h390-vm] building BREXX

One piece of the puzzle is this:

There is no DMSREX module in VM/370. René Ferland confirmed this.

The RESLIB command is used to load BREXX TEXT into resident storage.
RESLIB itself is not documented in the official VM/370 documents, I just read
the System Programmer’s guide and the CMS Commands and Macros guide.
It is documented by HELP RESLIB, and was written by Andrew Hanushevsky,
Langmuir Laboratory, Cornell University in 1980.

The HELP RESLIB (MORE command states that every program that is loaded in
this way, needs to be serially reusable (which is one step above/below
reentrant/reenterable, depending on how you see it). This means BREXX
may not have compiler initialized static variables. I wonder if GCC has an
option to make sure it does not, and I would be more at ease if it was
reentrant.

The loading is done for each VM/user by an exec called SYSPROF EXEC. I
found out by doing a RESLIB DELETE GCCLIB, RESLIB DELETE DMSREX for my
MAINT user, and trying to make it work again afterwards. It did not, because
the botched builds left a wrong SYSPROF EXEC on MAINT’s A disk, or that is
what I think.

As soon as I found this, and deleted the one on the A disk, the one on the V
disk is executed at logon and the info is correct again. Interestingly, the
modules GCCLIB and DMSREXX are loaded at different (virtual) address in
different userid’s. Then I remembered that the release notes for Sixpack 1.2
say:

? During initialization, CMS executes "SYSPROF EXEC" before
executing "PROFILE EXEC". This allows you to ensure certain commands are
always executed for users.


These commands are the RESLIB commands for BREXX; it then chains
SYSPROX EXEC for the mecaff programs.

I’ll keep you posted on more progress, for example whe I find out how the
exec processor finds it is a REXX exec, which is rather anachronistic for this
level of VM.

best regards,

René Jansen.

?

On Mon, Feb 10, 2020 at 09:59 PM, Dave Wade wrote:

What is holding me up is reporting proper versions

Cheat! Just add VERSION EXEC to the S drive (or wherever!) ?

?

Thanks Eddy!

?

With respect to GCCLIB problems here is Dr Hans Latz explanation of the problem:

?

---

Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#317) | Reply To Group | Reply To Sender | Mute This Topic | New Topic

Your Subscription | Contact Group Owner | Unsubscribe [rvjansen@...]

On 10 Feb 2020, at 21:46, eddy_balem@... wrote:

?

With respect to GCCLIB problems here is Dr Hans Latz explanation of the problem:

---

Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#317) | Reply To Group | Reply To Sender | Mute This Topic | New Topic

Your Subscription | Contact Group Owner | Unsubscribe [rvjansen@...]

_._,_._,_

On 10 Feb 2020, at 18:56, George Shedlock <gshedlock352@...> wrote:

Maybe I am missing something.

Is there something wrong with the IBM supplied utilities to install/maintain the system code?

I for one would prefer to use the old tried and true methods.

Possibly I am thinking of another version of VM (or possibly it was something we wrote in-house) but we used something called UPDATE which had the ability to start with the normal distributed (base) software and apply the entire library of fixes and updates to that code and build all of the necessary steps and modules to the running system. Of course we had to schedule an IPL from time to time to get some of the fixes installed.

I will dig through some old stuff and see if I can find some of the old notes and procedures we had.

George

On 2/10/2020 12:33 PM, adriansutherland67 wrote:

On Mon, Feb 10, 2020 at 05:05 PM, Dave Wade wrote:

if the sequence numbers are gone

In Assembler files right? No need to strip them out if we put it in GIT.

However, I suppose we might need a very simple tool to add new ones if lines are entered outside of VM/370? I assume the algorithm to make sequence numbers is triveral?

A

Virus-free.

?

On Mon, Feb 10, 2020 at 05:05 PM, Dave Wade wrote:

if the sequence numbers are gone

In Assembler files right? No need to strip them out if we put it in GIT.

However, I suppose we might need a very simple tool to add new ones if lines are entered outside of VM/370? I assume the algorithm to make sequence numbers is triveral?

A

?

Virus-free.

?

?

On Mon, Feb 10, 2020 at 05:05 PM, Dave Wade wrote:

if the sequence numbers are gone

In Assembler files right? No need to strip them out if we put it in GIT.

However, I suppose we might need a very simple tool to add new ones if lines are entered outside of VM/370? I assume the algorithm to make sequence numbers is triveral?

A

On Mon, Feb 10, 2020 at 05:05 PM, Dave Wade wrote:

if the sequence numbers are gone

In Assembler files right? No need to strip them out if we put it in GIT.

However, I suppose we might need a very simple tool to add new ones if lines are entered outside of VM/370? I assume the algorithm to make sequence numbers is triveral?

A

Virus-free.