On Mon, Mar 2, 2020 at 09:36 PM, adriansutherland67 wrote:

Robert left the following note:

?

TODO:? Detect if we are in resident memory, and if so, BALR to the system functions instead of using SVC 202

I am going to assume that this was an old comment and Robert had done the work already. The 3 places he used the svc202, well I think he was obliged to. For example there does not seem to be a balr for rename.

On Tue, Mar 3, 2020 at 12:58 AM, Bob Polmanter wrote:

And if you learned it, you would understand why S/370 doesn't need a stack and a heap and all that stuff, why its so powerful and efficient, and why it is still used for system level software, even today.

Thanks Bob, remember by unfamiliar or weird, well I don't mean bad!

On Tue, Mar 3, 2020 at 03:32 AM, Dave Wade wrote:

Ok a couple of points. SVC202 is NOT an OS emulation, it's pure CMS. There is code in PDPCLIB to use it I guess in the system() routine so you shouldn't need to re-invent the wheel.

Yep. It was Roberts own comment in the code that triggered the question

On Tue, Mar 3, 2020 at 02:10 AM, Peter Coghlan wrote:

If you are using Sixpack 1.3 beta 3 and you need EPLIST support, I can
talk you through how to fix the error I caused.

Thanks Peter I would appreciate that, it seems very likely that the problem I am seeing is caused a eplist issue. If it is just a glitch with beta 3 that would be good news :-)

If you could give me instructions, I will automate the fix in the docker images.?

In passing, the good news is David will have some very specific scripts / details as to what has been done to B3 (gcclib, brexx, eplist, etc.) for him to curate as he decides.

Bob wrote:

I dont believe that EPLIST is available either, although for some reason
it seems a bit familiar that someone enhanced this.? Maybe someone else
can answer this part.

EPLIST is available in at least some, maybe all except one of the Sixpack
distributions by virtue of enhancement HRC309DS. However, I must confess that
I am responsible for causing it to be broken in Sixpack 1.3 beta 3 (only). I
have alerted Dave to the problem and I expect it will be working again in the
next Sixpack release or beta release. Apologies for my foulup.

If you are using Sixpack 1.3 beta 3 and you need EPLIST support, I can
talk you through how to fix the error I caused. It is fairly
straightforward to do but it does involve some assembly (assembling some
source that is, not writing or modifying any assembly source). If you
don't want to go down that route, I'd suggest using Sixpack 1.3 beta 2
for now when you need EPLIST support.

Regards,
Peter Coghlan.

Adrian,

SVC 202 is the internal mechanism used to kick off CMS commands.? So for example you could programmatically set up a literal that contains a command like? 'ACC 111 J'? or 'FILEDEF? XXX TERM'.? The literal has to be broken into 8-character strings, e.g.,
CL8'ACC'
CL8'111'
CL8'J'

and terminated with 8X'FF' at the end of that.? When you execute SVC 202, CMS will perform that function.? I believe this is documented in one of the CMS manuals.? There are plenty of restrictions too.? You would probably have to call an assembler subroutine from C in order to use it, because the return from SVC 202 is a bit tricky.

You could use BALR for some system functions but of course you have to know where to BALR to.? That requires knowledge of internal control blocks and the use of dsect mapping macros.

You are getting into a bit of trouble because you are trying to mix things like C and GGCLIB and their ilk, with Assembler.

I dont believe that EPLIST is available either, although for some reason it seems a bit familiar that someone enhanced this.? Maybe someone else can answer this part.

I'd highly recommend that you take the time to learn assembler and make a meaningful stab at trying to use it.? If you get through a first project with it (and I dont mean Hello World), I don't believe you will ever want to go back.?? And if you learned it, you would understand why S/370 doesn't need a stack and a heap and all that stuff, why its so powerful and efficient, and why it is still used for system level software, even today.

Regards,
Bob

TODO:? Detect if we are in resident memory, and if so, BALR to the system functions instead of using SVC 202

On Sun, Mar 1, 2020 at 03:13 PM, Steven Fosdick wrote:

I fed hello pli through the PL/I F
compiler with the (L option to get it to include the generated code in
the listing

Thanks for doing that ... I have to say a find the GCC generated code less alien, I guess because I am familiar with what I am expecting it to try to do.

I will try and do a GCC listing with the optimiser turned on. It will be interesting to see how the registers are used.? Just for a giggle :-)

On Sun, Mar 1, 2020 at 09:06 PM, adriansutherland67 wrote:

And it is all is assembler :

Please be kind as I ask stupid questions ...

So I remembered that you needed to say "EXEC script"? - it then worked a bit!

The bad news is that there is a problem in the way that GCCLIB either reads arguments, or sets them up when calling CMScommand. And it is all is assembler :-( Anyway I will need to fix this - and maybe move logic to C. Maybe it is a logic error, maybe it is just not reentrant (I suspect this strongly).

Questions
- Does anyone care about EPLIST? The PLIST is simpler and we are talking VM/370, I could just rip EPLIST out :-)? Thoughts ????
- Where is the best reference to the PLIST/EPLIST format and calls?

The good news is that is you call a classic EXEC from rexx and that in turn calls a rexx program - well it all seems good, and behaves sanely :-)

Because the argument defect is no worse than what was there before, I have released it all - and is on the latest docker if people want to play.

Adrian

On Sun 01 Mar 2020 at 15:13:50 +0000, Steven Fosdick wrote:

Well that was interesting. I fed hello pli through the PL/I F
compiler with the (L option to get it to include the generated code in
the listing. I think I understand much of it, but I do have some
questions. I have commented on the main part of the listing with my
comments below the instruction they apply to:

- OBJECT LISTING

* STATEMENT NUMBER 1

* PROCEDURE HELLO

* REAL ENTRY HELLO
000000 47 F0 F 014 B 20(0,15)

Adrian commented on assembler not making much sense and the branch
instruction above certainly looks obscure but looking this up it is an
instruction for which the address is d+b+x where d is a displacement,
b is a base register and x is an index register and for some weird
reason IBM have come up with a syntax where it is written d(b,x) or
maybe d(x,b) - they are just two registers that get added to the
displacement. The gottcha is that zero doesn't mean register 0 but

That isn't *so* weird actually, lots of other CPUs have similar notation
where () around something means an indirection. DEC's PDP11 has it,
Motorola 680x0 too, MOS 6502 as well (LDA ($04),Y). Putting a number
next to it, with or without a comma, adds those values. For me the weird
thing is that IBM writes registers as just their number, not in a more
easy to recognize way such as R15.

There is some variation on the theme though. I believe some GNU
assemblers might have used (680x0) "MOV.L @SP+,D0" instead of Motorola's
"(SP)+". Although it isn't that strange either, since a double
indirection in a PDP-11 instruction like "MOV @1234(R1),R0" also uses an
@ sign.

In early Unix, @ was used as a line-editing character (erase line or
erase character, I always forget; in any case, # was the other) and
therefore early Unix assemblers used "MOV *(SP)+,R0" instead. And
that is probably how C got its indirection operator. $ was then used to
indicate an immediate operand. Both still look weird to me...

the value 0. So, if register 15 is set to the beginning of the code
then this jumps over the data that immediately follows to 000014 (20
in hex) and the STM instruction.

000004 DC AL1(5)
000005 DC C'HELLO'
00000A 07 00 NOPR 0
00000C 000000B8 DC F'184'
000010 00000000 DC A(SI.)

000014 90 EB D 00C STM 14,11,12(13)

Store multiple registers, starting at 14 and wrapping around to 11,
starting address 12 bytes past the address in register 13.

Note the somewhat weird convention in the calling sequence that the save
area for the CALLED function is supplied by the CALLER. There is only
space in here to store the registers. As long as the called function
needs no extra space, this saves work for leaf functions, but otherwise
they still need to create some workspace. And if they in turn call other
functions, they must supply a save area for them too.

000018 58 B0 F 010 L 11,16(0,15)

So this should be loading the contents of location 000010 into
register 11 - it is zero in this listing, how does it get set? Or
maybe it should be zero.

Since the value comes from "DC A(SI.)" (Address of SI.), it probably
gets filled in at load/link time.

00001C 58 00 F 00C L 0,12(0,15)

Load the contents of 00000C into register 0, i.e. the fixed point value 184.

F'184' means "Fullword" (4 bytes) I think?

000020 58 F0 B 020 L 15,32(0,11)

This looks like it is referring to a table of subroutine entries in
another module. If the base of that table was to be stored at 000010
by the loader such that this is now in register 11, this would set
register 15 to the 8th subroutine entry in that table.

000024 05 EF BALR 14,15

Call the subroutine whose address we just put in register 15 and put
the return address in register 14.

and its save area in R13, according to the official calling convention,
but since we didn't change R13, that probably isn't in use here.

000026 05 A0 BALR 10,0

Just put the return address in register 10. Don't actually call location zero.

where "return address" is the address following the BALR. This is
typically used to "establish addressability". When you write assembler
by hand, you'd typically also tell the assembler that you want to use
this register as base register from here on (USING *,R10, or R10,*, it
really has been ages since I last used this stuff). If you use an
instruction that references some label in your program, it will
automatically try to generate a base register + displacement for it. It
can do that if you tell it which registers will be pointing to where, at
runtime.

* PROLOGUE BASE
000028 41 90 D 098 LA 9,152(0,13)

Load address. It does the d+b+x calculation then put the calculated
address, rather than the value at that address, into the destination
register so set register 13 to 156 into save area/stack frame.

Register 9, I think.

00002C CL.5 EQU *
00002C 50 DC 0 000 ST 13,PR..HELLO(12)

Hm, did we get to see anything with register 12 yet?

000030 92 00 D 062 MVI 98(13),X'00'
000034 92 01 D 063 MVI 99(13),X'01'
000038 92 C0 D 000 MVI 0(13),X'C0'
00003C 41 A0 A 018 LA 10,CL.3

So is this setting up a list of passed parameters to a procedure call,
i.e. where register 1 will point to a list of addresses? Or is it
something slightly different like a file control block or some other
custom data structure for a call to the OS?

* PROCEDURE BASE
000040 CL.3 EQU *

* APPARENT ENTRY HELLO

* STATEMENT NUMBER 3
000040 92 03 D 063 MVI 99(13),X'03'
000044 41 10 B 06C LA 1,SKPL..04A4
000048 58 F0 B 044 L 15,A..IHEIOBC
00004C 05 EF BALR 14,15
00004E 41 10 B 054 LA 1,DV..C..03D4
000052 41 20 B 078 LA 2,DED..C..03D4
000056 58 F0 B 03C L 15,A..IHELDOB
00005A 05 EF BALR 14,15
CL.6 EQU *
00005C 92 03 D 063 MVI 99(13),X'03'
000060 58 F0 B 040 L 15,A..IHEIOBT
000064 05 EF BALR 14,15

So a series of subroutine calls that presumably implement the I/O
operation but nothing that looks like stack manipulation - this is all
done with register 13 unchanged. And what does the syntax with two
dots in a symbolic name mean, or even three dots?

It is not a notation I recall from using back then.

My first guess was that it's just a valid character for a name. Since
the names are likely limited to 8 characters, you'd want a few more
characters available than just letters to make the most of that.
On the other hand, these names are longer than that, so that leaves me
lost as well...

Probably the listing that is generated by the PL/I compiler isn't quite
complete enough that you could use it to run through the assembler.

* STATEMENT NUMBER 4
000066 92 04 D 063 MVI 99(13),X'04'
00006A 58 F0 B 030 L 15,A..IHESAFA
00006E 05 EF BALR 14,15

As this is the last instruction this appears to be a subroutine that
does not return. I don't know any of the names. Is this one "return
control to the OS"?

Likely...

-Olaf.
--
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___ Anyone who is capable of getting themselves made President should on
\X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"

Well that was interesting. I fed hello pli through the PL/I F
compiler with the (L option to get it to include the generated code in
the listing. I think I understand much of it, but I do have some
questions. I have commented on the main part of the listing with my
comments below the instruction they apply to:

- OBJECT LISTING

* STATEMENT NUMBER 1

* PROCEDURE HELLO

* REAL ENTRY HELLO
000000 47 F0 F 014 B 20(0,15)

Adrian commented on assembler not making much sense and the branch
instruction above certainly looks obscure but looking this up it is an
instruction for which the address is d+b+x where d is a displacement,
b is a base register and x is an index register and for some weird
reason IBM have come up with a syntax where it is written d(b,x) or
maybe d(x,b) - they are just two registers that get added to the
displacement. The gottcha is that zero doesn't mean register 0 but
the value 0. So, if register 15 is set to the beginning of the code
then this jumps over the data that immediately follows to 000014 (20
in hex) and the STM instruction.

000004 DC AL1(5)
000005 DC C'HELLO'
00000A 07 00 NOPR 0
00000C 000000B8 DC F'184'
000010 00000000 DC A(SI.)

000014 90 EB D 00C STM 14,11,12(13)

Store multiple registers, starting at 14 and wrapping around to 11,
starting address 12 bytes past the address in register 13.

000018 58 B0 F 010 L 11,16(0,15)

So this should be loading the contents of location 000010 into
register 11 - it is zero in this listing, how does it get set? Or
maybe it should be zero.

00001C 58 00 F 00C L 0,12(0,15)

Load the contents of 00000C into register 0, i.e. the fixed point value 184.

000020 58 F0 B 020 L 15,32(0,11)

This looks like it is referring to a table of subroutine entries in
another module. If the base of that table was to be stored at 000010
by the loader such that this is now in register 11, this would set
register 15 to the 8th subroutine entry in that table.

000024 05 EF BALR 14,15

Call the subroutine whose address we just put in register 15 and put
the return address in register 14.

000026 05 A0 BALR 10,0

Just put the return address in register 10. Don't actually call location zero.

* PROLOGUE BASE
000028 41 90 D 098 LA 9,152(0,13)

Load address. It does the d+b+x calculation then put the calculated
address, rather than the value at that address, into the destination
register so set register 13 to 156 into save area/stack frame.

00002C CL.5 EQU *
00002C 50 DC 0 000 ST 13,PR..HELLO(12)
000030 92 00 D 062 MVI 98(13),X'00'
000034 92 01 D 063 MVI 99(13),X'01'
000038 92 C0 D 000 MVI 0(13),X'C0'
00003C 41 A0 A 018 LA 10,CL.3

So is this setting up a list of passed parameters to a procedure call,
i.e. where register 1 will point to a list of addresses? Or is it
something slightly different like a file control block or some other
custom data structure for a call to the OS?

* PROCEDURE BASE
000040 CL.3 EQU *

* APPARENT ENTRY HELLO

* STATEMENT NUMBER 3
000040 92 03 D 063 MVI 99(13),X'03'
000044 41 10 B 06C LA 1,SKPL..04A4
000048 58 F0 B 044 L 15,A..IHEIOBC
00004C 05 EF BALR 14,15
00004E 41 10 B 054 LA 1,DV..C..03D4
000052 41 20 B 078 LA 2,DED..C..03D4
000056 58 F0 B 03C L 15,A..IHELDOB
00005A 05 EF BALR 14,15
CL.6 EQU *
00005C 92 03 D 063 MVI 99(13),X'03'
000060 58 F0 B 040 L 15,A..IHEIOBT
000064 05 EF BALR 14,15

So a series of subroutine calls that presumably implement the I/O
operation but nothing that looks like stack manipulation - this is all
done with register 13 unchanged. And what does the syntax with two
dots in a symbolic name mean, or even three dots?

* STATEMENT NUMBER 4
000066 92 04 D 063 MVI 99(13),X'04'
00006A 58 F0 B 030 L 15,A..IHESAFA
00006E 05 EF BALR 14,15

As this is the last instruction this appears to be a subroutine that
does not return. I don't know any of the names. Is this one "return
control to the OS"?

I have a good SDL-Hercules setup for VM/ESA V2.4 now. I can start and stop
it and login to MAINT or any of the other pre-configured users and shut it
down normally. All this is done with TK4- based automatic startup and
shutdown scripts.

I found somewhere in the VM/ESA documentation that the system supports a
maximum of 2047M in main storage and a separate maximum of 2047M in expanded
storage (XPNDSIZE in the Hercules configuration file). I am able to use
ARCHMODE ESAME and CPUMODEL 9672 without problems so far.

Now I want to configure the TCPIP setup.

The preconfigured system defines two external communication devices, 448 for
"VTAM SNA" as a P/390 "LAN3172" device and a pair of P/390 "LCS3172" devices
at 44A-44B for TCPIP.

My understanding at the moment is that Hercules does not yet support the
SNA-based "LAN3172" device, is that correct?

LCS3172 devices are known to me from configuring other IBM OS systems under
Hercules. My Hercules configuration statement for the TCPIP devices is:

044A-044B LCS -n 192.168.1.8 -m 02-AA-BB-CC-DD-EE 192.168.1.81

Where 192.168.1.8 is my host system Win10 IP address and 192.168.1.81 will
be this VM/ESA's IP address.

All good so far.

In the PROFILE TCPIP file under user TCPMAINT the pre-configured system
defines the 44A address as a token-ring device rather than as ethernet, so
the first change is to make it ethernet:

; 3172 44A/44B ETHERNET
DEVICE UNITY LCS 44A
LINK ETH44A ETHERNET 0 UNITY

The PROFILE TCPIP file also uses a range of 9.x.x.x IP addresses which I
presume I need to change to 192.168.x.x addresses, starting with the HOME
address and ignoring the static route definitions for other local systems
for now:

HOME
; local host InterNet addresses (SYS1)
192.168.1.81 ETH44A
; (End of HOME address information)

GATEWAY
; (IP) Network First Link Max. Packet Subnet Subnet
; Address Hop Name Size (MTU) Mask Value
; ----------- ------------ ------- ----------- ----------- --------
192.168.0.0 = ETH44A 1492 0.255.240.0 0.168.0.0
DEFAULTNET 192.168.1.1 ETH44A 1492 0.255.240.0 0
; (End of GATEWAY Static Routing information)

My router is at 192.168.1.1, is the 192.168.0.0 gateway definition correct
in the above change? I am especially unsure of the "Subnet Mask" and
"Subnet Value" settings, are they correct for a 192.168.x.x local network?

Then there is the HOSTS LOCAL file where the 9.x.x.x addresses also need to
be changed and I would comment out the "other" systems for now:

HOST : 192.168.1.81 : SYS1.P390.MYDOMAIN.ORG, SYS1 :::: ;
; HOST : 192.168.1.82 : SYS2.P390. MYDOMAIN.ORG, SYS2 :::: ;
; HOST : 192.168.1.83 : SYS3.P390. MYDOMAIN.ORG, SYS3 :::: ;
; HOST : 192.168.1.84 : SYS4.P390. MYDOMAIN.ORG, SYS4 :::: ;

Am I missing any other changes to get TCPIP up and running? Are any of the
changes I listed above incorrect?

I do know I may need to update the FTP server data file(s) but I thought I
should just start with basic TCPIP changes to begin with.

TIA for any assistance you can offer.

Peter

So I have finished making BREXX reentrant (recursive in fact) by moving all globals into a structure and popping and pushing it onto what I call the context stack.

At least 1 bug remains - but the reason I am posting is that I am having a hard time getting it to call itself.

In fact I cannot get it to call a simple non-rexx EXEC. And calling the other only way works if I specify 'DMSREX prog'.

There is also some bug wrt to the program name being missing when staring DMSREX! Obs I will investigate.

The question to the group is back in the days of VM/370 R6 what was the story / restrictions in calling a program from an EXEC and vice-versa and recursively, and what was CMS Subset mode (or is that a figment of my imagination). In sum, what is the art of the possible so far as the OS is concerned?

Cheers

A

开云体育

On the suggestion of seeing what the PL/I compiler generates, does
anyone have a similar hello world program or something else suitably
simple in PL/I to try compiling.  I really don't know PL/I.  Maybe
even better would be something that is recursive but not tail
recursive so it could not be optimised by the compiler into iteration
(or am I giving the compilers of the day too much credit?)

Ask and you shall receive.

The LCM+L 4361 has:

HELLO    BASIC    Y2
HELLO    C        Y2
HELLO    COBOL    Y2
HELLO    FORTRAN  Y2
HELLO    PASCAL   Y2
HELLO    PLC      Y2
HELLO    PLI      Y2
HELLO    SCRIPT   Y2
HELLO    SNOBOL4  Y2
HELLO    WATFIV   Y2

-ahd-

--

Drew Derbyshire

 The Postman hits! The Postman hits! You have new mail.

On 2/28/20 2:48 PM, adriansutherland67 wrote:

When a small small child first learns to read, when each letter is mouthed out slowly, every now and then a word is recognised, sometimes even correctly! Like that child I recognise that there is meaning in S/370 assembler, and sometimes I even guess at the meaning, and sometimes correctly (perhaps, who knows!)

Which of course, is how many of us learned to do assembler. That, and keeping the S/370 PoP at hand.? :-)

I remember being embarrassed as a freshman/sophomore at Clarkson because my friends knew Assembler and I didn't.? Of course, ten years later I was doing Assembler as a contractor for the VM/XA people in IBM Kingston, so I guess I made progress.

-ahd-

--
Drew Derbyshire

"There's no place like home." -- "The Wizard of Oz"

On Fri, 28 Feb 2020 at 19:42, Dave Wade <dave.g4ugm@...> wrote:

… look at the generated code…

OK, so here's a small C program I found on the sixpack, a variant of
the common hello world program:

#include <stdio.h>
int main(int argc, char * argv[]) {
printf("Good morning... from HELLO!\n");
}

and this is what gcc produces as assembler output:

COPY PDPTOP
CSECT
* Program text area
LC0 EQU *
DC C'Good morning... from HELLO!'
DC X'15'
DC X'0'
DS 0F
DC C'GCCMVS!!'
EXTRN @@CRT0
ENTRY @@MAIN
@@MAIN DS 0H
USING *,15
L 15,=V(@@CRT0)
BR 15
DROP 15
LTORG
* X-func main prologue
MAIN PDPPRLG CINDEX=0,FRAME=96,BASER=12,ENTRY=YES
B FEN0
LTORG
FEN0 EQU *
DROP 12
BALR 12,0
USING *,12
PG0 EQU *
LR 11,1
L 10,=A(PGT0)
* Function main code
MVC 88(4,13),=A(LC0)
LA 1,88(,13)
L 15,=V(PRINTF)
BALR 14,15
SLR 2,2
LR 15,2
* Function main epilogue
PDPEPIL
* Function main literal pool
DS 0F
LTORG
* Function main page table
DS 0F
PGT0 EQU *
DC A(PG0)
END @@MAIN

I suppose it would be interesting to see a version targeted at the
native CMS library rather than the PDP-like library. Also some of the
tricks are hidden in prologue/epilogue macros.

On the suggestion of seeing what the PL/I compiler generates, does
anyone have a similar hello world program or something else suitably
simple in PL/I to try compiling. I really don't know PL/I. Maybe
even better would be something that is recursive but not tail
recursive so it could not be optimised by the compiler into iteration
(or am I giving the compilers of the day too much credit?)

When a small small child first learns to read, when each letter is mouthed out slowly, every now and then a word is recognised, sometimes even correctly! Like that child I recognise that there is meaning in S/370 assembler, and sometimes I even guess at the meaning, and sometimes correctly (perhaps, who knows!)

Asking me to read S/370 is like asking a child to read Umberto Eco!

But I do try ... :-)

开云体育

I don’t think you do. Look at the generated code

?

What he said.

First off, you can have more than one base register; a reentrant module generally will have at least two: One for the code and one for data.

Secondly, you can always load/compute the full address of a variable in a register.?

-ahd-

-- 
Drew Derbyshire

"Whatever is not nailed down is mine. What I can pry loose is not
 nailed down."                                  -- Collis P. Huntingdon