[hercules-os380] A question about VM/370 SixPack 1.2.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

I hope I'm not "off topic", would be the case
just let me know and I'll move to the h390vm
my question.

I'm playing a bit outside MVS3.8j, trying to
get some confindence with VM/370.

I just installed from http://www.smrcc.org.uk/members/g4ugm/VM370.htm
the vm370sixpack-1.2 pack and I did some simple test, just to understand
where I'm.

Basic things seems to work, but I had a try running vm/370
under the hercules-3.07 with Paul patches for 380 mode.

I was glad to see, on the left upper corner of the login
VM screen, the "VM/370 ONLINE" becoming "VM/380 ONLINE".

So, I defined MAINSIZE=160 and tested, as CMSUSER,
the GCC compiler, simply compiling the "HELLO C"
sample on the CMSUSER A minidisk.

It is really a short compile test, but I'm pretty sure
I've seen addressing switching from "24" to "31" on
the hercules main panel, while GCC380 was executing.

Looking to "GCC EXEC S" I've seen the compiler is
switched from GCC370 to GCC380, if CHECK380 return "380",
which it actually does.

Now, what I should expect from this GCC380 compiler
and PDPCLIB?

May I malloc() in 31 bit mode using the standard GCC
compiler onboard of the vm370sixpack-1.2, while in
380-mode, using the patched 3.07 emulator?

Peppe.

P.S. By the way, Paul, I tested also the patched
3.13-380 emulator, it works exactly in the same
way of the 3.07-380 version:

"VM/380 ONLINE"
check380
Ready(00380); T=0.01/0.01 16:11:05

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I hope I'm not "off topic", would be the case
just let me know and I'll move to the h390vm
my question.

Here is the right place. H390-VM will
potentially get bile from the anti-380 crowd.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Now, what I should expect from this GCC380 compiler
and PDPCLIB?
May I malloc() in 31 bit mode using the standard GCC
compiler onboard of the vm370sixpack-1.2, while in
380-mode, using the patched 3.07 emulator?

The GCC build process builds a S/370 version
of PDPCLIB meaning any programs you produce
will only be capable of allocating 16 MiB.

If you want to produce 31-bit load modules
like GCC itself you will need to build a
S/380 version of PDPCLIB. Beta MVS/380
doesn't have this problem and all modules
produced are ANY/ANY.

Also, unlike *beta only* MVS/380, VM/380 is
very primitive only allowing a single ATL
GETMAIN. As such, you will need to activate
MEMMGR.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I hope I'm not "off topic", would be the case
just let me know and I'll move to the h390vm
my question.

Here is the right place. H390-VM will
potentially get bile from the anti-380 crowd.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Now, what I should expect from this GCC380 compiler
and PDPCLIB?
May I malloc() in 31 bit mode using the standard GCC
compiler onboard of the vm370sixpack-1.2, while in
380-mode, using the patched 3.07 emulator?

The GCC build process builds a S/370 version
of PDPCLIB meaning any programs you produce
will only be capable of allocating 16 MiB.

If you want to produce 31-bit load modules
like GCC itself you will need to build a
S/380 version of PDPCLIB. Beta MVS/380
doesn't have this problem and all modules
produced are ANY/ANY.

Also, unlike *beta only* MVS/380, VM/380 is
very primitive only allowing a single ATL
GETMAIN. As such, you will need to activate
MEMMGR.

BFN. Paul.

---

Thank you Paul. I understand, I need to do
the very same thing I've done for MVS3.8j,
i.e. compile a version of PDPCLIB with -DUSE_MEMMGR
and "&ZSYS SETC 'S380'", using the STAGE4Z JCL
stream.

I suspected that was the problem, thanks Paul
for confirming my suspect.

The problem now is: "how that can be done under VM/380"?

I mean, is there around a VM EXEC I may use to
recompile such a version (let me call it 380)
of PDPCLIB? What is onboard ov VM/370 Sixpack 1.2
is enough or do I need extra sources and/or files?

In alternative, does such a version already exist
around, ready to be downloaded and installed on
VM/380?

I did a fast google scan on this topic, but I
was able to find only this rather ancient link

https://www.quesearch.com/msgsdisp.php?parm=herculesos380-vm-380-31-bit-addressing-problem

about a 2009 thread of this group, a thread I didn't log
unfortunately, as it is precedent to my group subscription.

Thanks for any help, Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I mean, is there around a VM EXEC I may use to
recompile such a version (let me call it 380)
of PDPCLIB? What is onboard ov VM/370 Sixpack 1.2
is enough or do I need extra sources and/or files?

Is compile.exec on the sixpack?

It has a section in it. Search for pdp370. Up
to mkclib. But you will also need to change
XXX to USE in stdpdp.parm.

Let me know of any issues. Source is in git too.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
Source is in git too.

No. The gccmvs patch.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I mean, is there around a VM EXEC I may use to
recompile such a version (let me call it 380)
of PDPCLIB? What is onboard ov VM/370 Sixpack 1.2
is enough or do I need extra sources and/or files?

Is compile.exec on the sixpack?

It has a section in it. Search for pdp370. Up
to mkclib. But you will also need to change
XXX to USE in stdpdp.parm.

Let me know of any issues. Source is in git too.

BFN. Paul.

---

Yes, "COMPILE EXEC F" is on this

GCC691 691 F

minidisk of the GCCCMS VM of the sixpack-1.2,
what, I guess, is the GCC source minidisk.

But I can't see any 'MKCLIB EXEC' around on
the minidisks of the GCCCMS VM:

l mkclib * *
File not found.

But "MKPDPC EXEC" is there, although it doesn't seems
to work, as it is, at least used standalone.

The GCCE steps, executed over a temporary disk A,
which contains a working copy of minidisk F

EXEC GCCE START C &DISK (NOASM
EXEC GCCE STDIO C &DISK (NOASM
EXEC GCCE STDLIB C &DISK (NOASM
EXEC GCCE CTYPE C &DISK (NOASM
EXEC GCCE STRING C &DISK (NOASM
EXEC GCCE TIME C &DISK (NOASM
EXEC GCCE ERRNO C &DISK (NOASM
EXEC GCCE ASSERT C &DISK (NOASM
EXEC GCCE LOCALE C &DISK (NOASM
EXEC GCCE MATH C &DISK (NOASM
EXEC GCCE SETJMP C &DISK (NOASM
EXEC GCCE SIGNAL C &DISK (NOASM
EXEC GCCE __MEMMGR C &DISK (NOASM

works correctly, but GCCE creates "fname ASSEMBLE A"
instead of "fname S A".

Instead the exec "FIXCSECT EXEC"

FILEDEF SYSIN DISK &FILE S &DISK
FILEDEF SYSPRINT DISK &FILE ASSEMBLE &DISK (LRECL 80 RECFM F
NAMCSECT &CSECT
FILEDEF SYSPRINT CLEAR
FILEDEF SYSIN CLEAR

seems to act on "fname S A".

The same seems true for the GCCAONE steps, which, I guess,
are required:

EXEC GCCAONE CMSSUPA &SRC &ASMNAME
EXEC GCCAONE CMSSTART &SRC &ASMNAME

Mmm ... something looks wrong here Paul, at least
to my naive VM eyes.

GCCE creates "fname ASSEMBLE" datasets, while FIXCSECT
expects "fname S" datasets. Of course, it doesn' work.

I can't easily change these execs Paul, but I would like
to understand before going around hacking.

Peppe.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I mean, is there around a VM EXEC I may use to
recompile such a version (let me call it 380)
of PDPCLIB? What is onboard ov VM/370 Sixpack 1.2
is enough or do I need extra sources and/or files?

Is compile.exec on the sixpack?
It has a section in it. Search for pdp370. Up
to mkclib. But you will also need to change
XXX to USE in stdpdp.parm.
Let me know of any issues. Source is in git too.
BFN. Paul.
---
Yes, "COMPILE EXEC F" is on this
GCC691 691 F
minidisk of the GCCCMS VM of the sixpack-1.2,
what, I guess, is the GCC source minidisk.
But I can't see any 'MKCLIB EXEC' around on
l mkclib * *
File not found.
But "MKPDPC EXEC" is there, although it doesn't seems
to work, as it is, at least used standalone.
The GCCE steps, executed over a temporary disk A,
which contains a working copy of minidisk F
EXEC GCCE START C &DISK (NOASM
EXEC GCCE STDIO C &DISK (NOASM
EXEC GCCE STDLIB C &DISK (NOASM
EXEC GCCE CTYPE C &DISK (NOASM
EXEC GCCE STRING C &DISK (NOASM
EXEC GCCE TIME C &DISK (NOASM
EXEC GCCE ERRNO C &DISK (NOASM
EXEC GCCE ASSERT C &DISK (NOASM
EXEC GCCE LOCALE C &DISK (NOASM
EXEC GCCE MATH C &DISK (NOASM
EXEC GCCE SETJMP C &DISK (NOASM
EXEC GCCE SIGNAL C &DISK (NOASM
EXEC GCCE __MEMMGR C &DISK (NOASM
works correctly, but GCCE creates "fname ASSEMBLE A"
instead of "fname S A".
Instead the exec "FIXCSECT EXEC"
FILEDEF SYSIN DISK &FILE S &DISK
FILEDEF SYSPRINT DISK &FILE ASSEMBLE &DISK (LRECL 80 RECFM F
NAMCSECT &CSECT
FILEDEF SYSPRINT CLEAR
FILEDEF SYSIN CLEAR
seems to act on "fname S A".
The same seems true for the GCCAONE steps, which, I guess,
EXEC GCCAONE CMSSUPA &SRC &ASMNAME
EXEC GCCAONE CMSSTART &SRC &ASMNAME
Mmm ... something looks wrong here Paul, at least
to my naive VM eyes.
GCCE creates "fname ASSEMBLE" datasets, while FIXCSECT
expects "fname S" datasets. Of course, it doesn' work.
I can't easily change these execs Paul, but I would like
to understand before going around hacking.
Peppe.

Well, in some way I rebuilt PDPCLIB, using PDP380 and
USE_MEMMGR.

But the best I had been able to achieve, starting
a C program using this new PDPCLIB was:

DMSSMN133S INVALID GETMAIN OR FREEMAIN SPECIFICATION.
DMSABN148T SYSTEM ABEND A0A CALLED FROM F01F6C.

I guess I did something in really WRONG way, but I can't
understand where.

It seems the C program is calling GETMAIN in the wrong way.

Any idea Paul?

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Instead the exec "FIXCSECT EXEC"
FILEDEF SYSIN DISK &FILE S &DISK
FILEDEF SYSPRINT DISK &FILE ASSEMBLE &DISK (LRECL 80 RECFM F
NAMCSECT &CSECT
FILEDEF SYSPRINT CLEAR
FILEDEF SYSIN CLEAR
seems to act on "fname S A".

Hi Peppe.

You seem to have uncovered problems with
the build procedure. I need time to rebuild
GCC on CMS multiple times to see if I can
figure out what is wrong.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
DMSSMN133S INVALID GETMAIN OR FREEMAIN SPECIFICATION.
DMSABN148T SYSTEM ABEND A0A CALLED FROM F01F6C.

I don't know what is wrong here either.

I have these suggestions:

1. GCCCMS minidisk 491 is shipped with crud on
it from a different version of GCC/PDPCLIB, so I
needed to erase that minidisk prior to doing my
normal work.

2. Try running the entire build procedure, twice,
to see if you have a reproducible environment
that delivers a working product, and then try
customizing it to produce a pure 380 product
by setting &BLD = 380 at the top.

3. Try using the latest dev gcc which I can
provide.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Well, in some way I rebuilt PDPCLIB, using PDP380 and
USE_MEMMGR.
But the best I had been able to achieve, starting
DMSSMN133S INVALID GETMAIN OR FREEMAIN SPECIFICATION.
DMSABN148T SYSTEM ABEND A0A CALLED FROM F01F6C.

Hi Peppe.

I have uploaded a new version of GCCMVS:

https://groups.yahoo.com/neo/groups/hercules-os380/files/gcc-stage285.zip

which has the following files of interest (which
you will need to extract from the patch and
upload):

make380.exec
std380.parm
pdpone.exec
mkpdpc.exec

The first 3 are new and the 4th is an update.
You should be able to drop these in to the
sixpack you are using and there is a good
chance it will work.

It's working for me when I run "make380.exec"
at the end of my build process.

* Build 380 version of C library post-build
* EXEC MAKE380 &SRC

Example program is running AM31:

17:13:35 welcome to pdptest
17:13:35 main function is at 000201F4
17:13:35 first byte of main is 47
17:13:35 running as amode 31
17:13:35 allocating 10 bytes
17:13:35 m1 is 041303C0
17:13:35 allocating 20 bytes
17:13:35 m2 is 04130410
17:13:35 stack is around 0002FF24
17:13:35 printing arguments
17:13:35 argc = 4
17:13:35 arg 0 is <exec>
17:13:35 arg 1 is <PaulEdwards>
17:13:35 arg 2 is <was>
17:13:35 arg 3 is <Here>


The upload contains some cleaning up I did
since doing that test, so it will take another
3-4 hours before I have confirmation that the
cleanup didn't cause any issues. But it was
just minor stuff, you should be fine with that.

If you're still getting the above error, I will
need you to add some debug to the code
you are using, or you need to try again with
a dev distribution that is working for me.
Note that the sixpack 1.2 contains a very old
version of GCC.

BFN. Paul.

['Dave Wade' [e-mail] [hercules-os380]]

-----Original Message-----
Sent: 26 May 2018 08:55
Subject: Re: [hercules-os380] Re: A question about VM/370 SixPack 1.2.

Well, in some way I rebuilt PDPCLIB, using PDP380 and USE_MEMMGR.
But the best I had been able to achieve, starting a C program using
DMSSMN133S INVALID GETMAIN OR FREEMAIN SPECIFICATION.
DMSABN148T SYSTEM ABEND A0A CALLED FROM F01F6C.

Hi Peppe.
https://groups.yahoo.com/neo/groups/hercules-os380/files/gcc-
stage285.zip
which has the following files of interest (which you will need to extract from
the patch and
make380.exec
std380.parm
pdpone.exec
mkpdpc.exec
The first 3 are new and the 4th is an update.
You should be able to drop these in to the sixpack you are using and there is
a good chance it will work.
It's working for me when I run "make380.exec"
at the end of my build process.
* Build 380 version of C library post-build
* EXEC MAKE380 &SRC
17:13:35 welcome to pdptest
17:13:35 main function is at 000201F4
17:13:35 first byte of main is 47
17:13:35 running as amode 31
17:13:35 allocating 10 bytes
17:13:35 m1 is 041303C0
17:13:35 allocating 20 bytes
17:13:35 m2 is 04130410
17:13:35 stack is around 0002FF24
17:13:35 printing arguments
17:13:35 argc = 4
17:13:35 arg 0 is <exec>
17:13:35 arg 1 is <PaulEdwards>
17:13:35 arg 2 is <was>
17:13:35 arg 3 is <Here>
The upload contains some cleaning up I did since doing that test, so it will
take another
3-4 hours before I have confirmation that the cleanup didn't cause any
issues. But it was just minor stuff, you should be fine with that.
If you're still getting the above error, I will need you to add some debug to
the code you are using, or you need to try again with a dev distribution that is
working for me.
Note that the sixpack 1.2 contains a very old version of GCC.

If you produce this updated as a release I will put it on the 1.3 (or whatever its called when its released).
Been distracted from producing a release by

1. A cantankerous motor cycle, (has a safety switch on the clutch that plays up and stops it starting)
2. A P390 with a RAID that keeps going degraded,
3. GDPR and the Trafford and Hulme campaign for real ale web site
4. A wife who wants trellis putting up in the garden

Dave

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by 'Dave Wade' ***@gmail.com [hercules-os380]
If you produce this updated as a release I will
put it on the 1.3 (or whatever its called when
its released).

Don't wait on me. Just use the already-released
version. The next version will coincide with a new
version of PDOS. PDOS/3x0 failed on memmgr
and when I went to debug that, the bug moved,
so it will take some effort to debug. Plus someone
has been working on the 386 version of PDOS,
and I will wait for that to quieten, then I'll be in a
position to release everything. Oh, I'm also hoping
to get a version of PDPCLIB that works on
METAL C. But at least the good news is that
PDPCLIB has all the incredible technology that
I wanted. So does MVS/380, although it would
still be nice if MVS/380 recognized the LOC=32
parameter and produced a better MVS than
z/OS. But that's just icing on the cake, it is
already doing the multiple memory allocation
which changed the GCCMVS build as I could
discard MEMMGR.

BFN. Paul.

[Mike Schwab [e-mail] [hercules-os380]]

#4 has a strict biological deadline. If you miss planting time, you
have to wait to next year.

Post by 'Dave Wade' ***@gmail.com [hercules-os380]

-----Original Message-----
Sent: 26 May 2018 08:55
Subject: Re: [hercules-os380] Re: A question about VM/370 SixPack 1.2.

Well, in some way I rebuilt PDPCLIB, using PDP380 and USE_MEMMGR.
But the best I had been able to achieve, starting a C program using
DMSSMN133S INVALID GETMAIN OR FREEMAIN SPECIFICATION.
DMSABN148T SYSTEM ABEND A0A CALLED FROM F01F6C.

Hi Peppe.
https://groups.yahoo.com/neo/groups/hercules-os380/files/gcc-
stage285.zip
which has the following files of interest (which you will need to extract from
the patch and
make380.exec
std380.parm
pdpone.exec
mkpdpc.exec
The first 3 are new and the 4th is an update.
You should be able to drop these in to the sixpack you are using and there is
a good chance it will work.
It's working for me when I run "make380.exec"
at the end of my build process.
* Build 380 version of C library post-build
* EXEC MAKE380 &SRC
17:13:35 welcome to pdptest
17:13:35 main function is at 000201F4
17:13:35 first byte of main is 47
17:13:35 running as amode 31
17:13:35 allocating 10 bytes
17:13:35 m1 is 041303C0
17:13:35 allocating 20 bytes
17:13:35 m2 is 04130410
17:13:35 stack is around 0002FF24
17:13:35 printing arguments
17:13:35 argc = 4
17:13:35 arg 0 is <exec>
17:13:35 arg 1 is <PaulEdwards>
17:13:35 arg 2 is <was>
17:13:35 arg 3 is <Here>
The upload contains some cleaning up I did since doing that test, so it will
take another
3-4 hours before I have confirmation that the cleanup didn't cause any
issues. But it was just minor stuff, you should be fine with that.
If you're still getting the above error, I will need you to add some debug to
the code you are using, or you need to try again with a dev distribution that is
working for me.
Note that the sixpack 1.2 contains a very old version of GCC.

If you produce this updated as a release I will put it on the 1.3 (or whatever its called when its released).
Been distracted from producing a release by
1. A cantankerous motor cycle, (has a safety switch on the clutch that plays up and stops it starting)
2. A P390 with a RAID that keeps going degraded,
3. GDPR and the Trafford and Hulme campaign for real ale web site
4. A wife who wants trellis putting up in the garden
Dave

BFN. Paul.

------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Well, in some way I rebuilt PDPCLIB, using PDP380 and
USE_MEMMGR.
But the best I had been able to achieve, starting
DMSSMN133S INVALID GETMAIN OR FREEMAIN SPECIFICATION.
DMSABN148T SYSTEM ABEND A0A CALLED FROM F01F6C.

Hi Peppe.

I have uploaded a new version of GCCMVS:

https://groups.yahoo.com/neo/groups/hercules-os380/files/gcc-stage285.zip

which has the following files of interest (which
you will need to extract from the patch and
upload):

make380.exec
std380.parm
pdpone.exec
mkpdpc.exec

The first 3 are new and the 4th is an update.
You should be able to drop these in to the
sixpack you are using and there is a good
chance it will work.

It's working for me when I run "make380.exec"
at the end of my build process.

* Build 380 version of C library post-build
* EXEC MAKE380 &SRC

Example program is running AM31:

17:13:35 welcome to pdptest
17:13:35 main function is at 000201F4
17:13:35 first byte of main is 47
17:13:35 running as amode 31
17:13:35 allocating 10 bytes
17:13:35 m1 is 041303C0
17:13:35 allocating 20 bytes
17:13:35 m2 is 04130410
17:13:35 stack is around 0002FF24
17:13:35 printing arguments
17:13:35 argc = 4
17:13:35 arg 0 is <exec>
17:13:35 arg 1 is <PaulEdwards>
17:13:35 arg 2 is <was>
17:13:35 arg 3 is <Here>


The upload contains some cleaning up I did
since doing that test, so it will take another
3-4 hours before I have confirmation that the
cleanup didn't cause any issues. But it was
just minor stuff, you should be fine with that.

If you're still getting the above error, I will
need you to add some debug to the code
you are using, or you need to try again with
a dev distribution that is working for me.
Note that the sixpack 1.2 contains a very old
version of GCC.

BFN. Paul.

---

As I'm sure you understand, Paul, I'm as naive
as possible about VM/370.

I'll try to follow your guidelines and
see what will come out.

Thanks for now, Peppe.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Well, in some way I rebuilt PDPCLIB, using PDP380 and
USE_MEMMGR.
But the best I had been able to achieve, starting
DMSSMN133S INVALID GETMAIN OR FREEMAIN SPECIFICATION.
DMSABN148T SYSTEM ABEND A0A CALLED FROM F01F6C.

Hi Peppe.
https://groups.yahoo.com/neo/groups/hercules-os380/files/gcc-stage285.zip
which has the following files of interest (which
you will need to extract from the patch and
make380.exec
std380.parm
pdpone.exec
mkpdpc.exec
The first 3 are new and the 4th is an update.
You should be able to drop these in to the
sixpack you are using and there is a good
chance it will work.
It's working for me when I run "make380.exec"
at the end of my build process.
* Build 380 version of C library post-build
* EXEC MAKE380 &SRC
17:13:35 welcome to pdptest
17:13:35 main function is at 000201F4
17:13:35 first byte of main is 47
17:13:35 running as amode 31
17:13:35 allocating 10 bytes
17:13:35 m1 is 041303C0
17:13:35 allocating 20 bytes
17:13:35 m2 is 04130410
17:13:35 stack is around 0002FF24
17:13:35 printing arguments
17:13:35 argc = 4
17:13:35 arg 0 is <exec>
17:13:35 arg 1 is <PaulEdwards>
17:13:35 arg 2 is <was>
17:13:35 arg 3 is <Here>
The upload contains some cleaning up I did
since doing that test, so it will take another
3-4 hours before I have confirmation that the
cleanup didn't cause any issues. But it was
just minor stuff, you should be fine with that.
If you're still getting the above error, I will
need you to add some debug to the code
you are using, or you need to try again with
a dev distribution that is working for me.
Note that the sixpack 1.2 contains a very old
version of GCC.
BFN. Paul.
---
As I'm sure you understand, Paul, I'm as naive
as possible about VM/370.
I'll try to follow your guidelines and
see what will come out.
Thanks for now, Peppe.

Not completely sure of what I've done, Paul,
but now I've a "PDPCLIB TXTLIB A" dataset,
on the CMSUSER 191 minidisk, which seems
able to run succesfully "MEMTEST":

gcc memtest
Ready; T=0.36/0.48 18:08:48
load memtest
Ready; T=0.01/0.02 18:08:51
genmod memtest
Ready; T=0.01/0.01 18:08:54
memtest
addr 41303C0 approx 65 MB location
checksum is -54967290
addr 5443110 approx 84 MB location
checksum is 1908000006
Ready; T=6.04/6.04 18:09:01

while the hercules-3.13:380 console show "31" on
its status line.

It looks I've got a 31-bit PDPCLIB, Paul?

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
while the hercules-3.13:380 console show "31" on
its status line.
It looks I've got a 31-bit PDPCLIB, Paul?

Looks good to me, but I don't understand what
you mean by you don't know what you did. Did
you use the scripts I uploaded or did you
continue with your previous work?

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
while the hercules-3.13:380 console show "31" on
its status line.
It looks I've got a 31-bit PDPCLIB, Paul?

Looks good to me, but I don't understand what
you mean by you don't know what you did. Did
you use the scripts I uploaded or did you
continue with your previous work?

BFN. Paul.

---

I did so many "experiments" on the
GCCCMS minidisks, I'm not sure anymore
of the integrity of the contents.

I've to start from a fresh copy
of the Sixpacks-1.2 before I can
be sure of what I've done.

I may easily restart my tests,
as I worked on an "empty" Sixpacks
copy.

I basically used your EXECs, but
on the mininidsks I'm using there
is not PDPMAIN and I get an error
about a missing "START S".

But leave me the time to redo
what I've done on a fresh copy
of VM/370.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I basically used your EXECs, but
on the mininidsks I'm using there
is not PDPMAIN

Ok, delete the word "PDPMAIN'
from make380.exec as it is not
needed with the GCC on the
sixpack 1.2.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
and I get an error
about a missing "START S".

I don't know why that would occur.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I basically used your EXECs, but
on the mininidsks I'm using there
is not PDPMAIN

Ok, delete the word "PDPMAIN'
from make380.exec as it is not
needed with the GCC on the
sixpack 1.2.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
and I get an error
about a missing "START S".

I don't know why that would occur.

BFN. Paul.

---

Ok, I've redone my duty on a fresh copy
of the Sixpack-1.2.

I'm still not sure of what is going on
Paul, but for what I can see I need
to run MAKE380 twice to get a clean
execution.

On the first run the "STATE" command
reports the "fname S" datasets are missing,
but I guess this should be expected, isn't?

From the other side "MEMTEST" run correctly
with the new PDPCLIB, consistently and I have
beel also able to increase the MAXCHUNK size
from 30M to 60M.

Thanks Paul, now I've a "complete" VM/380
GCC environment.

Peppe.

P.S. A side question. I know "isn't?", as
I wrote above, it is not correct, the correct
shape should be "isn't it?", but I remember
I've seen many times, in many US mailing
lists, people writing just "isn't" at the
end of a phrase, a sort of "contraction".

Am I wrong?

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
On the first run the "STATE" command
reports the "fname S" datasets are missing,

That is not an error. Just ignore that, it
should work fine on the first go.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
but I guess this should be expected, isn't?

That use of "isn't" is not correct. Perhaps some
people use that as slang, but I haven't even
seen that as slang.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Thanks Paul, now I've a "complete" VM/380
GCC environment.

Great!

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
works correctly, but GCCE creates "fname ASSEMBLE A"
instead of "fname S A".

I was wondering what the effect of that would
be, and it should be that without rebuilding
the C code properly, MEMMGR should stay
in effect, and subsequently fail.

It's clearly not failing, and I was wondering
how that was possible.

I came up with a theory, and was able to
prove it.

I have made this code change:

C:\devel\pdos\pdpclib>git diff stdlib.c
diff --git a/pdpclib/stdlib.c b/pdpclib/stdlib.c
index d3cd5bd..59015a5 100644
--- a/pdpclib/stdlib.c
+++ b/pdpclib/stdlib.c
@@ -51,12 +51,15 @@ extern int __tso;
/* Note that you can set MAX_CHUNK to less than REQ_CHUNK */
/* But don't do this until MVS/380 etc have been changed to */
/* allow multiple memory requests. */
+/* But bump it up to 64 MiB so that if CMS is misconfigured */
+/* it tries to get almost 16 MiB so should fail */
+
#if defined(MULMEM)
-#define MAX_CHUNK 60000000
-#define REQ_CHUNK 60000000
+#define MAX_CHUNK 67108608
+#define REQ_CHUNK 67108608
#else
-#define MAX_CHUNK 60000000 /* maximum size we will store in memmgr */
-#define REQ_CHUNK 60000000 /* size that we request from OS */
+#define MAX_CHUNK 67108608 /* maximum size we will store in memmgr */
+#define REQ_CHUNK 67108608 /* size that we request from OS */
#endif
void *__lastsup = NULL; /* last thing supplied to memmgr */
#endif

C:\devel\pdos\pdpclib>


As per the IBM documentation:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa700/GETMAIN_Description.htm

LV=length value specifies the length, in bytes, of the requested virtual storage. The number should be a multiple of 8; if it is not, the system uses the next higher multiple of 8. If R is specified, LV=(0) may be coded; the low-order three bytes of register 0 must contain the length, and the high-order byte must contain the subpool number. LV=(maximum length value, minimum length value) specifies the maximum and minimum values of the length of the storage request.


So all this time, the S/370 utilities that have been
created on CMS have been using MEMMGR,
and getting memory from subpool 3:

C:\devel\pdos\pdpclib>zcalc 60000000/(16*1024*1024)
Calculated Value is 3.576279
Thank you for using the calculator

For a length of about 10 MB:

C:\devel\pdos\pdpclib>zcalc 60000000%(16*1024*1024)
Calculated Value is 9668352.000000
Thank you for using the calculator


With the code change in place, it attempts to
get nearly 16 MiB instead of 10 MB and now
my build process is failsafeing with:

12:41:21 DMSSMN109S VIRTUAL STORAGE CAPACITY EXCEEDED.
12:41:21 DMSABN148T SYSTEM ABEND 80A CALLED FROM F01F6C.


I will now fix the compile error and retry.

Stay tuned.

BFN. Paul.