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.
|
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
¸é±ð²Ô¨¦.
|
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
¸é±ð²Ô¨¦.
|
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.
|
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.
|
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.
|
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.
|
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 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 ...
|
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 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.
|
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:
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
|
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.)
|
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,
¸é±ð²Ô¨¦.
|
Re: VM/370 Hercules Optimisation
On Sat, 1 Feb 2020 at 20:22, Drew Derbyshire <swhobbit@...> wrote: Full screen CMS was/is a awful hack -- all the native CM/SP line
oriented output is intercepted using IUCV and redirected to the full
screen environment. And yes, because the output is written,
intercepted, and written again, it is a resource pig.
Full screen CMS also used command names that polluted the existing
namespace. For example in VM/SP 4 you simple could enter "HELP DEFINE"
to get the information on the CP command to define virtual devices, but
in VM/SP "HELP DEFINE" would return information on DEFINE WINDOW and
DEFINE VSCREEN. ("HELP CP DEFINE" was required for the old behavior.)
The first VM/SP version with full screen CMS is VM/SP 5. The LCM+L 4361
runs VM/SP 5, and yes, you can issue "SET FULLSCREEN ON" on it (may
Ceiling Cat have mercy on your virtual CPU). Tony H.
|
Re: Using the real card reader
Gentlemen - than you all for your help - sorted :-)
For future visitors ref?
- read * to read the fine from your rdr list. This is digestible -??-?(anyone, was there a r6 version?)
-? you also need a read control card, also fixed format (described in the punch cp help).
Example of the input file to hercules, which is routed to CMSUSER and which READ can then give the right name.?
toggle quoted message
Show quoted text
USERID? CMSUSER
:READ? TESTNAME TESTTYPE A1 CMS191 01/01/20? 18:20?
Test Punch file
Line 2 etc.
|
Re: Using the real card reader
You need a ¡°USERID¡± card with two spaces after the ¡°USERID¡±, e.g. ? USERID? GCCCMS ? on the front of the deck. Then do ? ¡°CP START ccu¡± ? On a user id with appropriate permissions. ?If you are using files then Judicious use of the ¡°EOF¡± and ¡°INTREQ¡± options allow you to have the USERID card in a separate file. ? Dave ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 02 February 2020 16:47
To: [email protected]
Subject: [h390-vm] Using the real card reader? Can someone help with the recipe for getting VP/CMS to read cards and spool to a user ... I am at a loss :-(
A the moment the device is drained.?
Thanks
Adrian
|
Re: Using the real card reader
Can someone help with the recipe for getting VP/CMS to read cards and spool
to a user ... I am at a loss :-(
the moment the device is drained.
You need to get it started. There can be some confusion because if you just enter the command: START 00C while logged on as MAINT for example, this will get passed to CMS which is not what you want and you will end up with an error something like this: ENTRY POINT '00C' NOT FOUND. Ready(00040); T=0.01/0.01 16:56:51 Try this command instead: CP START 00C and you should get a message something like this instead: RDR 00C STARTED SYSTEM Ready; T=0.01/0.01 17:01:04 Then, in order to cause a deck of cards to be spooled to a particular user, the first card should consist of something like: USERID CMSUSER for example to cause the cards to be spooled to CMSUSER. Regards, Peter Coghlan.
|
Re: Using the real card reader
Have you seen this video:?
At about 11m50s it describes adding a user ID card to the start of the deck (file) then goes on to show the Hercules devinit required.? Are you doig those things?
On Sun, 2 Feb 2020 at 16:47, adriansutherland67 < adrian@...> wrote: Can someone help with the recipe for getting VP/CMS to read cards and spool to a user ... I am at a loss :-(
A the moment the device is drained.?
Thanks
Adrian
|
