|
Hi,
I need some help in building BREXX. I wanted to have a look at some of the problems it has, and prepare for testing it if the new sixpack level comes out.
This is what I have done until now:
brexx source is on minidisk brexx 191
link brexx 191 202 mr
password
acc 202 j
I have put GCCLIB and PDPCLIB on RESLIB:
GLOBAL TXTLIB CMSLIB PLILIB FORTLIB TSOLIB GCCLIB PDPCLIB
GLOBAL MACLIB DMSGPI CMSHRC CMSLIB OSMACRO TSOMAC OPCODES
mkbrexx
¡
....
Compiling X2D
Loading BREXX...
Creating BREXX MODULE...
Creating BREXX TEXT for resident loading...
INPUT FILE 'MAIN TEXT J' NOT FOUND.
Ready(00028); T=108.89/131.73 22:58:05
This is correct because the .TEXT files ended up on my A disk.
If I load main test, I get errors
load main
THE FOLLOWING NAMES ARE UNDEFINED:
RXINITIA LSCPY RXRUN RXFINALI RXRETURN LCAT LREAD
More of these errors are to be found in the file BREXX MAP on the J disk. So this is where I am stuck at the moment.
I would also like to know how the interface to exec works. In z/VM, DMSREX is called by this, and it turn calls IXXRIN. I cannot find a DMSREX on V/370. I know of the conventions to choose Madnick¡¯s EXEC, EXEC2 or REXX. I assume there is no EXEC2 on VM/370 but I did not check.
A few days ago I read about plans to setup a github repository for VM/370 so we could have the latest sources and maybe an way to file issues. I would be a proponent of this. I saw that the brexx repository recently forked on github, for the version that now runs on MVS 3.8 TK4-. I have a fork of the brexx repository on rvjansen/brexx (for some pull requests I made for the macos build procedure) and I will try to keep up the cms code in there, and, for the moment, keep my CMS brexx issues, but I¡¯d rather we¡¯d move to a more central github repository which keeps all of the VM/370 sources.
I have great respect for the way the procedure works on VM, but this, and for example, SMP/E, are not really geared to modern day open source collaboration. I would love to hear if someone made the effort, I think it would be a good thing for the community.
As a start, I wiil enter these issues in my github issue list:
BREXX bugs
1) HX or HI sometimes do not work. User needs to be forced off to stop some scripts, for example the well known WHENRUBO EXEC.
2) Odd problem with file not found with STATE:
File written: REXXVERS EXEC A1
Ready; T=0.02/0.04 00:36:54
type rexxvers exec
/* REXX */
PARSE VERSION X
SAY X
Ready; T=0.01/0.01 00:37:02
rexxvers
--¡ú Cannot find the just edited and saved file
fopen error: file 'STATE REXXVERS *' not found.
Error 58 running "REXXVERSC": File not found
Ready; T=0.02/0.03 00:37:09
--¡ú copy it to another file
copyfile rexxvers exec a version exec a
Ready; T=0.01/0.01 00:37:47
version
bREXX 2.1.8 Aug 6 2010
Ready; T=0.02/0.03 00:37:52
--¡ú after the copy IT CAN FIND IT ????
rexxvers
bREXX 2.1.8 Aug 6 2010
Ready; T=0.02/0.03 00:39:50
3) Overwrite of storage
DMSABN149T 109 (HEX 00006D) DOUBLEWORDS OF SYSTEM STORAGE HAVE BEEN DESTROYED. RE-IPL CMS.
CP ENTERED; DISABLED WAIT PSW '00020000 6001F04E'
4) I/O functions flakey (LINEIN, LINEOUT) (Gerard Wassink complained recently on the Moshix Discord)
5) Leaving out arguments but then trying to use them is a recipe for dumps.
best regards,
¸é±ð²Ô¨¦.
|
So I would support this and started with CMSLIB. I?have a repository with buildable code.
I want to set up a GitHub action so that code can be built automatically on a push, and a release (on a tape) produced on a tag.?
I am nearly there:.? ?
- I have a VM/370 docker container for the runner
- I have made herccontrol that allows me to automate the build through a script
- I have yata (yet another text archive), a light weight tool to allow me to send source code via the punch reader to cms. This autobuilds (as above) but it needs a change to handle lines over 80 characters. The point is it is a simple c program that builds on CMS, Linux, or Windows.
So I just need to do yata and set up the script for CMSLIB and then I can tackle some bugs in it. And then move to do the same to other facilities, etc.
All on GitHub under adesutherland
My lesson learnt is that GitHub actions are painful to debug!
It would be amazing to work with folks to have a repository for CP and for CMS, and so on. Each building automatically and running some tests. And a master repository that builds distributions from fresh with different configurations (min size, everything, everything with source, Fortran, c, COBOL, etc.)
|
On Sat, Feb 8, 2020 at 11:55 PM, rvjansen@... wrote:
GLOBAL TXTLIB CMSLIB PLILIB FORTLIB TSOLIB GCCLIB PDPCLIB
Are you sure you want CMSLIB? This will interfere with gcclib.? Cmslib is a CMS native (rather than os emulated) stdc lib. I suspect brexx builds with gcclib currently ... Adrian
|
On Sat, Feb 8, 2020 at 11:55 PM, rvjansen@... wrote:
3) Overwrite of storage
This might just be a known defect with the version of cmslib installed on 6pack 1.3 beta 3. This is what started me down the winding road ...
|
On Sat, Feb 8, 2020 at 11:55 PM, rvjansen@... wrote:
) I/O functions flakey (LINEIN, LINEOUT) (Gerard Wassink complained recently on the Moshix Discord)
Not knowing if brexx is linked to gcclib or cmslib ... I would want it linked to cmslib ... and it is here that any io should be sorted.
|
adriansutherland67 wrote:
On Sat, Feb 8, 2020 at 11:55 PM, rvjansen@... wrote:
GLOBAL TXTLIB CMSLIB PLILIB FORTLIB TSOLIB GCCLIB PDPCLIB
Are you sure you want CMSLIB? This will interfere with gcclib.
Cmslib is a CMS native (rather than os emulated) stdc lib.
CMSLIB TXTLIB contains these five members: IEAXPSIM IEAXPALL IEAXKALL IEAXPDXR IEAXKDXR What have any of these to do with any C runtime library? Regards, Peter Coghlan.
|
On Sun, Feb 9, 2020 at 11:16 AM, Peter Coghlan wrote:
CMSLIB TXTLIB contains these five members:
Peter, you are right, I am talking nonsense! I always get mixed up. I mean GCCLIB not CMSLIB!!? Notice to all ...? whenever I say CMSLIB please read GCCLIB ... So GCCLIB is the CMS native stdc lib and PDPCLIB is Paul's os macro version. You don't want both ...
|
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.
|
To see what CMS mods there are in the n-Pack logon to maint and type
CMSACC
This accesses the CMS modifications disk as "B" and then do
EE HRCMODS MEMO B
You will see HRC371DS implements this change. So
MEMO HRC371DS B1
Will contain details of how this is implemented.
Dave
toggle quoted message
Show quoted text
-----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.
|
Ah!
Thanks Dave!
¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
On 9 Feb 2020, at 23:25, Dave Wade <dave.g4ugm@...> wrote:
To see what CMS mods there are in the n-Pack logon to maint and type
CMSACC
This accesses the CMS modifications disk as "B" and then do
EE HRCMODS MEMO B
You will see HRC371DS implements this change. So
MEMO HRC371DS B1
Will contain details of how this is implemented.
Dave
-----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.
|
Rene,
When you logon to maint the CP mods disk is accessed as "B". There is another HRCMODS MEMO on that disk for the CP mods.
Dave
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 22:36
To: [email protected]
Subject: Re: [h390-vm] building BREXX
Ah!
Thanks Dave!
¸é±ð²Ô¨¦.
On 9 Feb 2020, at 23:25, Dave Wade <dave.g4ugm@...> wrote:
To see what CMS mods there are in the n-Pack logon to maint and type
CMSACC
This accesses the CMS modifications disk as "B" and then do
EE HRCMODS MEMO B
You will see HRC371DS implements this change. So
MEMO HRC371DS B1
Will contain details of how this is implemented.
Dave
-----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.
|
ok. Another beginner¡¯s question: I see the original source of DMSEXC ASSEMBLE is from 1978, and changes are patched on using a line-by-line approach. Is there some easy way to assemble the source module with all the patches merged, so that I can check the offsets without going through the whole rebuild of the system? Would this be one of those VMFxxx commands?
¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
On 9 Feb 2020, at 23:41, Dave Wade <dave.g4ugm@...> wrote:
Rene,
When you logon to maint the CP mods disk is accessed as "B". There is another HRCMODS MEMO on that disk for the CP mods.
Dave
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 22:36
To: [email protected]
Subject: Re: [h390-vm] building BREXX
Ah!
Thanks Dave!
¸é±ð²Ô¨¦.
On 9 Feb 2020, at 23:25, Dave Wade <dave.g4ugm@...> wrote:
To see what CMS mods there are in the n-Pack logon to maint and type
CMSACC
This accesses the CMS modifications disk as "B" and then do
EE HRCMODS MEMO B
You will see HRC371DS implements this change. So
MEMO HRC371DS B1
Will contain details of how this is implemented.
Dave
-----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.
|
Ren¨¦ Jansen wrote:
ok. Another beginner¡¯s question: I see the original source of
DMSEXC ASSEMBLE is from 1978, and changes are patched on using a
line-by-line approach. Is there some easy way to assemble the source
module with all the patches merged, so that I can check the offsets
without going through the whole rebuild of the system? Would this
be one of those VMFxxx commands?
If by "assemble" you mean "run the assembler on", use this command: VMFASM DMSEXC DMSHRC If you mean "produce a source file with all the patches applied", use this one: UPDATE DMSEXC ASSEMBLE * DMSHRC CNTRL * (CTL and look at the file called $DMSEXC ASSEMBLE. Regards, Peter Coghlan
¸é±ð²Ô¨¦.
|
Hi Peter,
I meant running the assembler on the source file with all the patches applied, so I can get a listing with the offsets, for me to be able to put stops in for looking at the data when it executes under the debugger. Thank you for this, it is just what I need.
best regards,
¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
On 10 Feb 2020, at 00:10, Peter Coghlan <groups@...> wrote:
Ren¨¦ Jansen wrote:
ok. Another beginner¡¯s question: I see the original source of
DMSEXC ASSEMBLE is from 1978, and changes are patched on using a
line-by-line approach. Is there some easy way to assemble the source
module with all the patches merged, so that I can check the offsets
without going through the whole rebuild of the system? Would this
be one of those VMFxxx commands?
If by "assemble" you mean "run the assembler on", use this command:
VMFASM DMSEXC DMSHRC
If you mean "produce a source file with all the patches applied", use this one:
UPDATE DMSEXC ASSEMBLE * DMSHRC CNTRL * (CTL
and look at the file called $DMSEXC ASSEMBLE.
Regards,
Peter Coghlan
¸é±ð²Ô¨¦.
|
Rene, Have you read "what mother never told you"? /g/h390-vm/files/What%20Mother%20Never%20Told%20You%20About%20VM%20Service%20%281983%29.pdfand the "SYSPROG MEMO" describes some of the mods. So if you want to assemble a CMS modules do CMSACC VMFASM modulename DMSHRC (DISK Will assemble the module and leave the listing as "$modulename LISTING" on the A disk. It will also leave a text deck. If you don't want that add "NODECK" to the options. I also believe that many of the BREXX problems are caused by its mis use of the DOS flag. Do you have some tests to show the problems? Dave
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 22:51
To: [email protected]
Subject: Re: [h390-vm] building BREXX
ok. Another beginner¡¯s question: I see the original source of DMSEXC
ASSEMBLE is from 1978, and changes are patched on using a line-by-line
approach. Is there some easy way to assemble the source module with all
the patches merged, so that I can check the offsets without going through
the whole rebuild of the system? Would this be one of those VMFxxx
commands?
¸é±ð²Ô¨¦.
On 9 Feb 2020, at 23:41, Dave Wade <dave.g4ugm@...> wrote:
Rene,
When you logon to maint the CP mods disk is accessed as "B". There is another HRCMODS MEMO on that disk for the CP mods.
Dave
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 22:36
To: [email protected]
Subject: Re: [h390-vm] building BREXX
Ah!
Thanks Dave!
¸é±ð²Ô¨¦.
On 9 Feb 2020, at 23:25, Dave Wade <dave.g4ugm@...> wrote:
To see what CMS mods there are in the n-Pack logon to maint and type
CMSACC
This accesses the CMS modifications disk as "B" and then do
EE HRCMODS MEMO B
You will see HRC371DS implements this change. So
MEMO HRC371DS B1
Will contain details of how this is implemented.
Dave
-----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.
|
He wants a listing, needs the "DISK" option on the VMFASM
Dave
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Peter
Coghlan
Sent: 09 February 2020 23:11
To: [email protected]
Subject: Re: [h390-vm] building BREXX
Ren¨¦ Jansen wrote:
ok. Another beginner¡¯s question: I see the original source of DMSEXC
ASSEMBLE is from 1978, and changes are patched on using a line-by-line
approach. Is there some easy way to assemble the source module with
all the patches merged, so that I can check the offsets without going
through the whole rebuild of the system? Would this be one of those
VMFxxx commands?
If by "assemble" you mean "run the assembler on", use this command:
VMFASM DMSEXC DMSHRC
If you mean "produce a source file with all the patches applied", use this one:
UPDATE DMSEXC ASSEMBLE * DMSHRC CNTRL * (CTL
and look at the file called $DMSEXC ASSEMBLE.
Regards,
Peter Coghlan
¸é±ð²Ô¨¦.
|
Hello! Adrian how did you construct this Docker Container? And is it available for us to work with? Dave, a question, since this concerns the sixpack. How does one launch it? (Together with how to log into it?) And this will be obvious only to the Yeti working with two people and many cats all over a museum in PA. But not to the people, only the cats and the yeti. ----- Gregg C Levine gregg.drwho8@... "This signature fought the Time Wars, time and again." On Sun, Feb 9, 2020 at 3:16 AM adriansutherland67 <adrian@...> wrote:
So I would support this and started with CMSLIB. I have a repository with buildable code.
I want to set up a GitHub action so that code can be built automatically on a push, and a release (on a tape) produced on a tag.
I am nearly there:.
- I have a VM/370 docker container for the runner
- I have made herccontrol that allows me to automate the build through a script
- I have yata (yet another text archive), a light weight tool to allow me to send source code via the punch reader to cms. This autobuilds (as above) but it needs a change to handle lines over 80 characters. The point is it is a simple c program that builds on CMS, Linux, or Windows.
So I just need to do yata and set up the script for CMSLIB and then I can tackle some bugs in it. And then move to do the same to other facilities, etc.
All on GitHub under adesutherland
My lesson learnt is that GitHub actions are painful to debug!
It would be amazing to work with folks to have a repository for CP and for CMS, and so on. Each building automatically and running some tests. And a master repository that builds distributions from fresh with different configurations (min size, everything, everything with source, Fortran, c, COBOL, etc.)
_._,_._,_
________________________________
Groups.io Links:
"And this space is being left blank.:
|
Hi Gregg,
You can probably just run it and it will download it from Docker Hub the first time, when the disk seek for it fails.
Yeah, tried to get my cats interested but they said they only accept paying assignments, and will not work on OS¡¯es without mice. So unless one foots the Purina, it¡¯s bleak.
¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
On 10 Feb 2020, at 02:43, Gregg Levine <gregg.drwho8@...> wrote:
?Hello!
Adrian how did you construct this Docker Container? And is it
available for us to work with?
Dave, a question, since this concerns the sixpack. How does one launch
it? (Together with how to log into it?)
And this will be obvious only to the Yeti working with two people and
many cats all over a museum in PA. But not to the people, only the
cats and the yeti.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."
On Sun, Feb 9, 2020 at 3:16 AM adriansutherland67
<adrian@...> wrote:
So I would support this and started with CMSLIB. I have a repository with buildable code.
I want to set up a GitHub action so that code can be built automatically on a push, and a release (on a tape) produced on a tag.
I am nearly there:.
- I have a VM/370 docker container for the runner
- I have made herccontrol that allows me to automate the build through a script
- I have yata (yet another text archive), a light weight tool to allow me to send source code via the punch reader to cms. This autobuilds (as above) but it needs a change to handle lines over 80 characters. The point is it is a simple c program that builds on CMS, Linux, or Windows.
So I just need to do yata and set up the script for CMSLIB and then I can tackle some bugs in it. And then move to do the same to other facilities, etc.
All on GitHub under adesutherland
My lesson learnt is that GitHub actions are painful to debug!
It would be amazing to work with folks to have a repository for CP and for CMS, and so on. Each building automatically and running some tests. And a master repository that builds distributions from fresh with different configurations (min size, everything, everything with source, Fortran, c, COBOL, etc.)
_._,_._,_
________________________________
Groups.io Links: "And this space is being left blank.:
|
Gregg,
Launching the six-pack...
For Linux make sure you have the latest BETA, have installed Hercules and x3270 and have a desktop.
Unpack the zip, make the sixpack.sh executable, do "./sixpack.sh" from wherever you unpacked it from.
It will start Hercules and a X3270 session.
The operator session is started as an integrated 3210.
Log into whatever user you want on the 3270 session.
For windows you need a "hercules" command prompt from which you type "sixpack"
Dave
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Gregg Levine
Sent: 10 February 2020 01:42
To: [email protected]
Subject: Re: [h390-vm] building BREXX
Hello!
Adrian how did you construct this Docker Container? And is it available for us
to work with?
Dave, a question, since this concerns the sixpack. How does one launch it?
(Together with how to log into it?)
And this will be obvious only to the Yeti working with two people and many
cats all over a museum in PA. But not to the people, only the cats and the
yeti.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."
On Sun, Feb 9, 2020 at 3:16 AM adriansutherland67
<adrian@...> wrote:
So I would support this and started with CMSLIB. I have a repository with
buildable code.
I want to set up a GitHub action so that code can be built automatically on a
push, and a release (on a tape) produced on a tag.
I am nearly there:.
- I have a VM/370 docker container for the runner
- I have made herccontrol that allows me to automate the build through
a script
- I have yata (yet another text archive), a light weight tool to allow me to
send source code via the punch reader to cms. This autobuilds (as above) but
it needs a change to handle lines over 80 characters. The point is it is a simple
c program that builds on CMS, Linux, or Windows.
So I just need to do yata and set up the script for CMSLIB and then I can
tackle some bugs in it. And then move to do the same to other facilities, etc.
All on GitHub under adesutherland
My lesson learnt is that GitHub actions are painful to debug!
It would be amazing to work with folks to have a repository for CP and
for CMS, and so on. Each building automatically and running some
tests. And a master repository that builds distributions from fresh
with different configurations (min size, everything, everything with source,
Fortran, c, COBOL, etc.) _._,_._,_ ________________________________
Groups.io Links:
"And this space is being left blank.:
|
On Mon, Feb 10, 2020 at 01:43 AM, Gregg Levine wrote:
Adrian how did you construct this Docker Container? And is it
available for us to work with?
You need docker desktop (or run it on a cloud provider's infrastructure). Then: docker run --rm -d -p 3270:3270 -p 8038:8038 -p 3505:3505 --name vm370 adriansutherland/vm370:1.3.5 (so the dockerhub page is? Notes: - first download is slow, after that it uses a cache - the --rm option deletes the container (and DASD changes) when Hercules exits. You may want to miss out that option if you want to re-launch the specific container instance and save your DASD change etc.!!?- you can connect to localhost:3270 for 3270; 8038 for web console, 3505 for card reader - It is setup to start Hercules but it does not ipl - so IPL 141 at the console. - The image includes c3270 - so you have the option to attach to it via a normal ssh console and run c3270 - version 1.3.5 is the most recent. If you use the version "latest" you currently get version 1.3.4 (older version of HercControl, no card reader) but I will obviously up version latest as per my "roadmap" in due course Other hints - To attach to the container: docker exec -it vm370 /bin/bash - you could then run c3270 - To stop/start the container: docker start? vm370 / docker stop? vm370 - copy files with docker cp The source is here: Notes: - I have master, develop (and from time to time feature) branches - so switch to develop for the latest and greatest, etc. - There is the Dockerfile, and a build.sh script (uses HercControl) - in .github/workflows are the action scripts that automatically cause the image to be build/tested. These look so simple but are are very irritating to debug! - A tag causes a release that pushes an image to dockerhub and makes a zip file with the DASD files in the release page. At the moment tied to the DASD files from the excellent six pack - when my build scripts starts adding updates (e,g, GCCLIB, fullscreen stuff, BREXX updates whatever) automatically, I am hoping Dave and community will be inspired to build scripts to automate the build from a basic baseline (if that makes sense).
|
