[hercules-os380] automatically building MVS

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

I was going through the Moseley web pages
to see if his procedure for building MVS from
scratch was automatable.

It all looks doable so long as you don't mind
having hardcoded delays and rely on message
numbering being predictable.

However, on this page:

http://www.jaymoseley.com/hercules/installMVS/icustom.htm

he says:

"Note: You must use a tn3270 client for the generated MVS 3.8j console and not a telnet client as we have been using for the starter system console."


The automation I prefer relies on an integrated
console, ie 3215-C.

I'm wondering whether the Moseley instructions
involve creating a system configuration that
cannot support a 3215 console and thus a
3270 console is a requirement.

And if so, is it possible to change that so that
a 3215 is always available, so that "nice"
automation is always available?

I am wondering whether the ideal is to have
automated procedures that give us some
checkpoints, noting that the checkpoints
themselves may change.

1. Original installation tapes from IBM.

2. Moseley or similar procedure used to
create a usable MVS, including 3390 disks.
Changes probably restricted to IBM
products.

3. TK4- restricted to adding applications,
not changing MVS.

4. MVS/380 restricted to adding S/380
MVS changes plus applications not accepted
into TK4-.

Although that process wouldn't create a
"pure MVS 3.8j" environment that only
supported 3350 disks in case a purist
wanted to try that. Perhaps that could
be some sort of "branch" created at a
later date, to replace number 2 above.

BFN. Paul.

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

Post by ***@yahoo.com.au [hercules-os380]
I was going through the Moseley web pages

to see if his procedure for building MVS from
scratch was automatable.

It all looks doable so long as you don't mind
having hardcoded delays and rely on message
numbering being predictable.

However, on this page:

http://www.jaymoseley.com/hercules/installMVS/icustom.htm

he says:

"Note: You must use a tn3270 client for the generated MVS 3.8j console and not a telnet client as we have been using for the starter system console."


The automation I prefer relies on an integrated
console, ie 3215-C.

I'm wondering whether the Moseley instructions
involve creating a system configuration that
cannot support a 3215 console and thus a
3270 console is a requirement.

And if so, is it possible to change that so that
a 3215 is always available, so that "nice"
automation is always available?

I am wondering whether the ideal is to have
automated procedures that give us some
checkpoints, noting that the checkpoints
themselves may change.

1. Original installation tapes from IBM.

2. Moseley or similar procedure used to
create a usable MVS, including 3390 disks.
Changes probably restricted to IBM
products.

3. TK4- restricted to adding applications,
not changing MVS.

4. MVS/380 restricted to adding S/380
MVS changes plus applications not accepted
into TK4-.

Although that process wouldn't create a
"pure MVS 3.8j" environment that only
supported 3350 disks in case a purist
wanted to try that. Perhaps that could
be some sort of "branch" created at a
later date, to replace number 2 above.

BFN. Paul.

---


Paul, I'm doing all of my work on Moseley
SYSGEN from a 3215-C console, I don't even
touch a 3270 console.

Minor changes are needed to Moseley STAGE1
to support a 3215-C console at IPL time, if
I remember correctly, something like that
(a diff from my Moseley "hell" ;-))

56a57,58

Post by ***@yahoo.com.au [hercules-os380]
AREA=04, C00570003
PFK=12, C00580003

71,72c73,76
< UNIT=3215, C00730003
< ADDRESS=009 00750003
---

Post by ***@yahoo.com.au [hercules-os380]
UNIT=3277, C00730003
MODEL=2, C00740003
ADDRESS=009, C00750003
FEATURE=(EBKY3277,DOCHAR,KB78KEY,AUDALRM,NUMLOCK,SELPEN)00760003

in sysgen01.jcl.

It just a small change in the console configuration
which allow to IPL from a 3215-C console:

# ----------------------------------------------- consoles
0010 3270 console # master console
#0009 3270 console # alternate console (not required)
0009 3215-C
#0009 3215
0015 1403 mvslog.txt # hardcopy of master console

and at the same time to use a 3270 master console
if even needed.

I understand the details are a bit confused, Paul,
I'm definitely not that good when time to document
my changes come ;-(

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, I'm doing all of my work on Moseley
SYSGEN from a 3215-C console, I don't even
touch a 3270 console.

Ok, cool.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Minor changes are needed to Moseley STAGE1
to support a 3215-C console at IPL time, if
I remember correctly, something like that
(a diff from my Moseley "hell" ;-))
in sysgen01.jcl.

Ok. So what do you think about doing a
context diff of the changes you made,
and then applying that as a patch?

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I'm definitely not that good when time to document
my changes come ;-(

Well they don't really need to be documented
if they are simply included in an automatic
script to build the system you are trying to
build.

What do you think about creating some auto
scripts?

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, I'm doing all of my work on Moseley
SYSGEN from a 3215-C console, I don't even
touch a 3270 console.

Ok, cool.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Minor changes are needed to Moseley STAGE1
to support a 3215-C console at IPL time, if
I remember correctly, something like that
(a diff from my Moseley "hell" ;-))
in sysgen01.jcl.

Ok. So what do you think about doing a
context diff of the changes you made,
and then applying that as a patch?

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I'm definitely not that good when time to document
my changes come ;-(

Well they don't really need to be documented
if they are simply included in an automatic
script to build the system you are trying to
build.

What do you think about creating some auto
scripts?

BFN. Paul.

---

For what I've seen so far, Paul, automating
the Moseley SYSGEN is going to be a nightmare.

I understand it may be useful, but, I guess,
Moseley SYSGEN, as the Volker TK3 SYSGEN, it
is not that easy to handle, even manually.

And most of the "pleasure" in performing such
a work is coming from modifying the J.Moseley
JCL streams, for understanding or to get new
features alive.

So far, I don't feel any need to automate
the process, but I'm still in the middle
of an ancient "abandoned" track.

I'm still trying to understand, and change,
the Moseley code.

Actually I'm trying to get ... how
to call it ... an "hybrid" ... between the Moseley
and the Volker SYSGEN.

Both the approaches, from my point of view,
have pro and cons.

I'm trying to get the best from both and,
at the same time, gaining some knowledge
on MVS and SMP.

But you know, as Greg Price just defined me ...
it seems I'm a "maverick".

I don't know if I'm, but for sure I just learned
a new english word ;-)

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I'm trying to get the best from both and,
at the same time, gaining some knowledge
on MVS and SMP.

If you believe you may be creating a system
that is better than both Moseley and Volker,
maybe you should be preserving the steps
used to create this system. And the best
way to do that is after you understand a
change you are making, to automate it.

Just something to think about. :-)

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
But you know, as Greg Price just defined me ...
it seems I'm a "maverick".
I don't know if I'm, but for sure I just learned
a new english word ;-)

You haven't seen "Top Gun"? One of the guys
was called "Maverick". And then there's the
"Hot Shots" sendup, where "Ice Man" has
been replaced by "Mail Man". Can't remember
the others.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
For what I've seen so far, Paul, automating
the Moseley SYSGEN is going to be a nightmare.

Can you explain why? I'd like to understand
what is required, regardless of whether you
(or anyone else, maybe even me) actually
do it or not. I'm unlikely to do it myself
unless I could actually use it for MVS/380,
which will not likely be the case because
I would instead use TK4- as the base.

On the other hand, maybe a MVS 3.8j
flavor that (eventually) supports a pure 3390
environment would be a useful thing to
have, even if TK4- never directly uses it.
Once the technology is proven (and
reproducible via automation), maybe
TK4- will switch to it, even if via a
different route.

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I'm trying to get the best from both and,
at the same time, gaining some knowledge
on MVS and SMP.

If you believe you may be creating a system
that is better than both Moseley and Volker,
maybe you should be preserving the steps
used to create this system. And the best
way to do that is after you understand a
change you are making, to automate it.

Just something to think about. :-)

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
But you know, as Greg Price just defined me ...
it seems I'm a "maverick".
I don't know if I'm, but for sure I just learned
a new english word ;-)

You haven't seen "Top Gun"? One of the guys
was called "Maverick". And then there's the
"Hot Shots" sendup, where "Ice Man" has
been replaced by "Mail Man". Can't remember
the others.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
For what I've seen so far, Paul, automating
the Moseley SYSGEN is going to be a nightmare.

Can you explain why? I'd like to understand
what is required, regardless of whether you
(or anyone else, maybe even me) actually
do it or not. I'm unlikely to do it myself
unless I could actually use it for MVS/380,
which will not likely be the case because
I would instead use TK4- as the base.

On the other hand, maybe a MVS 3.8j
flavor that (eventually) supports a pure 3390
environment would be a useful thing to
have, even if TK4- never directly uses it.
Once the technology is proven (and
reproducible via automation), maybe
TK4- will switch to it, even if via a
different route.

BFN. Paul.

---

Paul, the "best for me".

MVS is an highly configurable system, which may
be customized in "uncountable" ways.

I don't even think I may get near what
matematicians call a "critical point",
by the way, critical for what?

I've just "feelings", feelings which change
along the way. TK4 is not far from a configuration
I love and it came from TK3. Juergen has done
a wonderful job over the Volker base layout.

From the other side, the Moseley SYSGEN is easier,
for me, to follow than the the Volker SYSGEN.

And it is not even such easy to follow what Juergen
has done over the Volker configuration.

I need to understand both before even thinking
to formalize what I actually want.

You ask why, in my opinion, it would be a nightmare
to automate such a process, Paul? Automate what? ;-)

By the way, my experiments with a 3380 RESVOL, has
been drived mostly from my curiosity. I don't think
I'm even near the knowledge needed to get a 3390
environment ready. Maybe Kevin may help in such
a task. I can't.

I've some notes written down (short and rather
difficult to read, even for me ;-) ) about what
I've done for a TK3 SMP environment over the
Moseley SYSGEN. Maybe they may be of some help
if you want to get down the road of a "maverick".

By the way. Remember I'm not a native english
speaker, so, while I've seen "Top Gun", I didn't
even notice that "Maverick" ;-)

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I don't even think I may get near what
matematicians call a "critical point",
by the way, critical for what?

Critical for retiring 3350s and 3330s for good,
other than as a novelty system that is used for
about 10 minutes, not to produce code or
anything of use whatsoever.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I've just "feelings", feelings which change
along the way.

That's what I have too, and I try to get
them into code where they will be
preserved.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
You ask why, in my opinion, it would be a nightmare
to automate such a process, Paul? Automate what? ;-)

Automate (ie put into script) the commands
you used to get to where you are.

That way when I say "please show me the
JES2 error you got", you just need to copy
your existing script, delete the last 3 lines,
then run it before you go to sleep, and in
the morning show me the JES2 errors.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, my experiments with a 3380 RESVOL, has
been drived mostly from my curiosity. I don't think
I'm even near the knowledge needed to get a 3390
environment ready. Maybe Kevin may help in such
a task. I can't.

Different people are willing to do different
things. Kevin producing a 3390 and then
losing it, is unfortunate. If your work gets
lost too, that may well be unfortunate too.

If you present an error to Kevin, he may
well be willing to fix it, so long as you do
the testing. I have no idea. Or someone
else might volunteer. Again, I have no idea.
People just randomly contribute in these
groups.

I don't know much/anything about SYSGENs
so I'm just throwing that out there as a
suggestion.

Think of how many people were involved
getting printers changed from AUTO to
OPERATOR. Any single missed person
and we wouldn't have had the required fix.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

Simply put, it will not be possible to build a 3380/3390 system using the
processes described in the Moseley docs.

It might be possible to build a 3380 system on a modified moseley system,
because the MVS3.8J sysgen docs say that it is supported.

The thing that we have to remember is that we are "starting" with a 3.7
system, which has no clue about anything later than a 3350. Putting on the
Morrison mods allows the 3.7 system to "know" about 3375/80/90, but not
build an IPL image for them (this is what Kevin was talking about in the
ACCEPT SMP processing). The SMP processes in the moseley sysgen process
bring the 3.7 system to a point where it can sysgen a 3.8 system (i.e. the
DLIBS now contain 3.8 code and PTFS).

Thus, when the sysgen process happens for the 3.8 system, it is taking
place on a modified 3.7 system in the current moseley docs. (Modified
because it has the Morrison mods applied).

So, what we need to do is build a moseley 3.8J system without any DASD mods
as a "base or starter" system, just the way it would've come from IBM (i.e.
only 3350 support).

Then, we can apply the DASD mods from Morrison/Leonard and because we now
are using a 3.8J system as the "starter", it has a more than 50/50 chance
of working to natively build a 3380 RESVOL since the DLIBS will now be at a
3.8 level. versus a 0% chance on the 3.7 system.

Joe

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I don't even think I may get near what
matematicians call a "critical point",
by the way, critical for what?

Critical for retiring 3350s and 3330s for good,
other than as a novelty system that is used for
about 10 minutes, not to produce code or
anything of use whatsoever.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I've just "feelings", feelings which change
along the way.

That's what I have too, and I try to get
them into code where they will be
preserved.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
You ask why, in my opinion, it would be a nightmare
to automate such a process, Paul? Automate what? ;-)

Automate (ie put into script) the commands
you used to get to where you are.
That way when I say "please show me the
JES2 error you got", you just need to copy
your existing script, delete the last 3 lines,
then run it before you go to sleep, and in
the morning show me the JES2 errors.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, my experiments with a 3380 RESVOL, has
been drived mostly from my curiosity. I don't think
I'm even near the knowledge needed to get a 3390
environment ready. Maybe Kevin may help in such
a task. I can't.

Different people are willing to do different
things. Kevin producing a 3390 and then
losing it, is unfortunate. If your work gets
lost too, that may well be unfortunate too.
If you present an error to Kevin, he may
well be willing to fix it, so long as you do
the testing. I have no idea. Or someone
else might volunteer. Again, I have no idea.
People just randomly contribute in these
groups.
I don't know much/anything about SYSGENs
so I'm just throwing that out there as a
suggestion.
Think of how many people were involved
getting printers changed from AUTO to
OPERATOR. Any single missed person
and we wouldn't have had the required fix.
BFN. Paul.

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

Post by Joe Monk ***@gmail.com [hercules-os380]
So, what we need to do is build a moseley
3.8J system without any DASD mods as a
"base or starter" system, just the way it
would've come from IBM (i.e. only 3350 support).

Sounds logical to me. I'm surprised there
is mucking around with the MVS 3.7
system at all. Maybe it was easier to do
that at the time, but yeah, the way you
are doing things sounds more logical to me.

ie use the MVS 3.7 system unchanged
to just get an MVS 3.8j like IBM intended,
and then use that as a base to create an
MVS 3.8j+ system, which would then be
an additional base.

Good luck!

BFN. Paul.

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

Hi Paul & All,

Some time back, I wrote some scripts that automate the building of the Moseley system. As I recall, I actually got quite far, automating the web page steps and instructions. If there is interest, I will look for them on Sunday when I get back from vacation.

ScottC

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

Post by ***@yahoo.com [hercules-os380]
Some time back, I wrote some scripts that
automate the building of the Moseley system.
As I recall, I actually got quite far, automating
the web page steps and instructions. If there
is interest, I will look for them on Sunday
when I get back from vacation.

Yes, please preserve your work by uploading
it to the files area etc, regardless of whether
someone commits to use them immediately.

Thanks. Paul.

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

Hi All,

I have located the previous work I had done, automating building Jay Moseley's MVS 3.8j system, circa 2013-07-14 using Hercules 3.07.


Apparently, since that time, Jay has EXTENSIVELY reworked that portion of his website and the entire build process. My build scripts follow the prior version of his website. I have included the historical webpages in the docs folder in the jaymoseley_build archive.


The entire Windows archive is located here: https://www.4shared.com/zip/xG8uDDE5ei/jaymoseley_scripts_circa201307.html https://www.4shared.com/zip/xG8uDDE5ei/jaymoseley_scripts_circa201307.html


Unzip the 2 folders in the archive to your c:\ root directory and run: run_jm_install.bat from the jaymoseley_build archive. If you prefer not to locate the 2 folders in the c:\ root directory on your system, then some minor changes to the install scripts will be necessary.


The entire process takes 10-15 minutes on my Windows 10, HP Pavilion i3 laptop.


Note: The output directory of the install is: c:\hercules. If that folder already exists on your system, it will be renamed to c:\hercules_b4moseley.


Let me know if anyone tries the install.


Thanks,
ScottC

Post by ***@yahoo.com [hercules-os380]
Some time back, I wrote some scripts that
automate the building of the Moseley system.
As I recall, I actually got quite far, automating
the web page steps and instructions. If there
is interest, I will look for them on Sunday
when I get back from vacation.

Yes, please preserve your work by uploading
it to the files area etc, regardless of whether
someone commits to use them immediately.

Thanks. Paul.

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

Post by ***@yahoo.com [hercules-os380]
Apparently, since that time, Jay has EXTENSIVELY reworked that portion
of his website and the entire build process. My build scripts follow
the prior version of his website. I have included the historical
webpages in the docs folder in the jaymoseley_build archive.

Almost impossible to keep the Jay Moseley JCL streams as they are ;-)

As I wrote, changing them is the first thing that come in mind,
after using them for a while, at least for me.

And once changed ... any automation done ... is gone ... ;-)

What would help in this type of task is a different hercules
console with a completely different console language.

In this way ... maybe ...

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
What would help in this type of task is a different hercules
console with a completely different console language.

Can you elaborate? What's wrong with
the current hercules console and
language?

BTW, after clicking about 8 different
buttons on 4shared that said "download",
it seems that you need to log in to
4shared before you can do a download.

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
What would help in this type of task is a different hercules
console with a completely different console language.

Can you elaborate? What's wrong with
the current hercules console and
language?

BTW, after clicking about 8 different
buttons on 4shared that said "download",
it seems that you need to log in to
4shared before you can do a download.

BFN. Paul.

---

Nothing is "wrong", it works.

But is not enough for the complexity we
would face automating, in a parametric way
(read: easy to change), a giant task like
the Jay Moseley MVS3.8j SYSGEN.

The hercules console environment just
allow to answer to a fixed string
with a fixed command, every time
the string is in output on the console.

Not enough, in my humble opinion.

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
The hercules console environment just
allow to answer to a fixed string
with a fixed command, every time
the string is in output on the console.

Ok, true, you can't analyze an MVS
message and then reply to the
appropriate number, e.g. R 5,Y.

This is not a problem if you are
automating a task that should be
predictable/deterministic, as pretty
much everything I do is.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Not enough, in my humble opinion.

BSPPILOT may do what you want, so
you might look at installing that as part
of your process.

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
The hercules console environment just
allow to answer to a fixed string
with a fixed command, every time
the string is in output on the console.

Ok, true, you can't analyze an MVS
message and then reply to the
appropriate number, e.g. R 5,Y.

This is not a problem if you are
automating a task that should be
predictable/deterministic, as pretty
much everything I do is.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Not enough, in my humble opinion.

BSPPILOT may do what you want, so
you might look at installing that as part
of your process.

BFN. Paul.

---

Well, the road leading from
the MVS3.7 starter kit to an MVS3.8j
fully installed, with BSPPILOT configured,
up and running is long ... ;-)

Peppe.

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

Hi Peppe,

Well, the question may come down to whether you want to be able to replicate the process of building your system from start to finish. If you want to build it once, using backups to fall back on, then maybe using build automation scripts may not be relevant to you.


I built the JayMoseley installation scripts, mainly just as an interesting challenge to see if it could be done. I think I proved it possible! :)


If anyone wants me to post the scripts on a different website, other than 4shared, please let me know.


ScottC

---In hercules-***@yahoogroups.com, <***@vitillaro.org> wrote :

Well, the road leading from
the MVS3.7 starter kit to an MVS3.8j
fully installed, with BSPPILOT configured,
up and running is long ... ;-)

Peppe.

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

Post by ***@yahoo.com [hercules-os380]
Hi Peppe,
Well, the question may come down to whether you want to be able to
replicate the process of building your system from start to finish. If
you want to build it once, using backups to fall back on, then maybe
using build automation scripts may not be relevant to you.
I built the JayMoseley installation scripts, mainly just as an
interesting challenge to see if it could be done. I think I proved it
possible! :)

I'm sure it is possible.

I was questioning about who would use it.

The main goal of the Jay Moseley SYSGEN is ... well ...
educational, in our days, where TK3/TK4- is already available
for who just wants to run a fully functional MVS3.8j.

And if anyone wants to "learn" about building a completely
new MVS3.8j layout, which is neither a Moseley, neither a TK3/TK4- ...
well the first thing to do ... is changing the Moseley JCL.

So ... just my 2 cents posts in this thread.

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I was questioning about who would use it.
The main goal of the Jay Moseley SYSGEN is ... well ...
educational, in our days, where TK3/TK4- is already available
for who just wants to run a fully functional MVS3.8j.

Well, I would suggest that if we eventually
get to the stage where commercial users
want to start using it, it may require some
sort of pedigree. E.g. brexx is copyrighted
software and not free for commercial use.
Is there a list of such software and would
you trust that list if you were running a
company?

I don't know what the build process is for
TK4-, but if an enterprise wants to ensure
that they are building a system only with
software that they know about, and are
confident about (e.g. do you want to
install that magic SVC, if it still exists,
to allow anyone to get into supervisor
mode?), then I think it would be logical to
start from the original MVS tapes and then
be selective of what you add.

So original tapes plus a long script to set
everything up would produce a clean
system I think.

Such use may well be years away, or even
never, who knows, but I still think it is good
to have a well-understood build script.

Note that it took something like 15 years
between someone writing the original
i370 machine definition in GCC to actually
having someone using it to run GCC itself
on normal MVS. Imagine if the original
author had balked at writing the machine
definition because he (correctly) didn't see
any serious user of it in the next 5 years.

BFN. Paul.

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

Post by ***@yahoo.com.au [hercules-os380]
sort of pedigree. E.g. brexx is copyrighted
software and not free for commercial use.
Is there a list of such software and would
you trust that list if you were running a
company?

And even if the answer is "yes" and "yes",
you still require a script to uninstall all the
things you don't think are appropriate to
your company, starting from the TK4- base.

Wouldn't you have more confidence going
the other way, ie installing rather than
uninstalling?

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I was questioning about who would use it.
The main goal of the Jay Moseley SYSGEN is ... well ...
educational, in our days, where TK3/TK4- is already available
for who just wants to run a fully functional MVS3.8j.

Well, I would suggest that if we eventually
get to the stage where commercial users
want to start using it, it may require some
sort of pedigree. E.g. brexx is copyrighted
software and not free for commercial use.
Is there a list of such software and would
you trust that list if you were running a
company?

I don't know what the build process is for
TK4-, but if an enterprise wants to ensure
that they are building a system only with
software that they know about, and are
confident about (e.g. do you want to
install that magic SVC, if it still exists,
to allow anyone to get into supervisor
mode?), then I think it would be logical to
start from the original MVS tapes and then
be selective of what you add.

So original tapes plus a long script to set
everything up would produce a clean
system I think.

Such use may well be years away, or even
never, who knows, but I still think it is good
to have a well-understood build script.

Note that it took something like 15 years
between someone writing the original
i370 machine definition in GCC to actually
having someone using it to run GCC itself
on normal MVS. Imagine if the original
author had balked at writing the machine
definition because he (correctly) didn't see
any serious user of it in the next 5 years.

BFN. Paul.

---

At this moment Paul, I'm more concerned understanding
the differences between the Volker's TK3 PTFs tape

allptfs.het 14188988 (length)

and the Moseley's PTFs tape

ptfs.het 14214177 (length).

It seems they contain a different set of PTFS and
I would be glad if anyone may help me identifying
why and where are the differences.

Even the MVS product tapes

zdlib1.het 16886283 (TK3)
product.het 18377742 (Moseley)

are rather different.

Damn ... ;-)

By the way, I know I may read the IBM SMP manual, but it is
a bit difficult and I'm a bit lazy these days, after a
rather bad flue.

Anyone may help me understanding the JCL needed to list
ACCEPTED and APPLIED PTFS under MVS3.8j?

I need also to understand if I got the right idea of
the difference between ACCEPTED and APPLIED mods.

If I got it right ACCEPTS mods are installed over the DLIB,
so they are "permanently" stored and available while generating
a new MVS, while APPLIED mods are installed ONLY on the current
system, and ONLY after the JCLIN SYSGEN phase is completed.

Is the right picture?

Peppe.

P.S. Beside that problem with VATLST00 (still to understand)
my 3380 Moseley SYSGEN seems to work correctly, I had
been able to APPLY PTFS and MODS, so even the SMP datasets
seems ok.

I think I'm going to test 3390 ... ;-)

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
At this moment Paul, I'm more concerned understanding
the differences between the Volker's TK3 PTFs tape
allptfs.het 14188988 (length)
and the Moseley's PTFs tape
ptfs.het 14214177 (length).

This is all part of establishing pedigree, so
I hope you are successful in figuring all
these issues out.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I think I'm going to test 3390 ... ;-)

Great stuff! I really hope we can retire non-3390s.

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, I know I may read the IBM SMP manual, but it is
a bit difficult and I'm a bit lazy these days, after a
rather bad flue.
Anyone may help me understanding the JCL needed to list
ACCEPTED and APPLIED PTFS under MVS3.8j?
I need also to understand if I got the right idea of
the difference between ACCEPTED and APPLIED mods.
If I got it right ACCEPTS mods are installed over the DLIB,
so they are "permanently" stored and available while generating
a new MVS, while APPLIED mods are installed ONLY on the current
system, and ONLY after the JCLIN SYSGEN phase is completed.
Is the right picture?
Peppe.
P.S. Beside that problem with VATLST00 (still to understand)
my 3380 Moseley SYSGEN seems to work correctly, I had
been able to APPLY PTFS and MODS, so even the SMP datasets
seems ok.
I think I'm going to test 3390 ... ;-)

Ops, the VATLST00 error was my fault ;-(

I completely forgot I deleted all the 3390 from
3380 STAGE1 ... so ... 3390 was missing from the
configuration:

IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2
HHC1C001A Enter input for console device 0009
/(0009)
IEF165I // START JES2
*00 IFB010D ENTER 'IPL REASON,SUBSYSTEM ID' OR 'U'
IEE360I SMF NOW RECORDING ON SYS1.MANX ON PEP380 TIME=12.52.32
AUTO COMMANDS IN COMMND00 BEING PROCESSED CN=00
IEF677I WARNING MESSAGE(S) FOR JOB JES2 ISSUED
*01 $HASP426 SPECIFY OPTIONS - HASP-II, VERSION JES2 4.1
/(0009) r 00,u
IEE600I REPLY TO 00 IS;U
IGF992I MIH INIT COMPLETE, PRI=000300, SEC=000015
/(0009) r 01,noreq
IEE600I REPLY TO 01 IS;SUPPRESSED
$HASP493 JES2 QUICK-START IS IN PROGRESS

The 3380 RESVOL is up and running without any
error and 3390 are now on its STAGE1, as
"d u,dasd,offline" show:

18E 3380 18F 3380 190 3390 191 3390 192 3390 193 3390 194 3390

Guess I may proceed with a 3390 RESVOL test now.

And I'm really curious to see what happens
using the Moseley SYSGEN with the TK3 tapes ;-)

Peppe.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, I know I may read the IBM SMP manual, but it is
a bit difficult and I'm a bit lazy these days, after a
rather bad flue.

I hope your chimney gets unclogged soon <G>

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Anyone may help me understanding the JCL needed to list
ACCEPTED and APPLIED PTFS under MVS3.8j?

There is a LISTCDS program on the optional source: CBTCOV.FILE022. I
also have a modified version that doesn't require all the original's
contortion, but I'm not sure where I got it. The ASMTRACE proc is
basically an ASMFCLG with debug support.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
*00 IFB010D ENTER 'IPL REASON,SUBSYSTEM ID' OR 'U'

There is a "fix" for this, but it's a ZAP only (probably used it before
SMP came out):

//MVSIFB10 JOB (0904,0012),GERHARD,CLASS=E
// EXEC SYSZAP,PDS=LPALIB
*
* THIS ZAP BYPASSES THE USELESS IFB010D WTOR (SPECIFY U OR
* IPL REASON - USELESS BECAUSE IT DOES NOT LET YOU
* SPECIFY THE REASON FOR THE IPL)
*
NAME IFBSVC76
VER 0648 0A23 WTOR
VER 064E 4100,0001,0A01 WAIT
*
REP 0648 0700
REP 064E 92E4,9000,0700 REPLY='U'
*


Gerhard Postpischil
Bradford, VT


---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, I know I may read the IBM SMP manual, but it is
a bit difficult and I'm a bit lazy these days, after a
rather bad flue.

I hope your chimney gets unclogged soon <G>

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Anyone may help me understanding the JCL needed to list
ACCEPTED and APPLIED PTFS under MVS3.8j?

There is a LISTCDS program on the optional source: CBTCOV.FILE022. I
also have a modified version that doesn't require all the original's
contortion, but I'm not sure where I got it. The ASMTRACE proc is
basically an ASMFCLG with debug support.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
*00 IFB010D ENTER 'IPL REASON,SUBSYSTEM ID' OR 'U'

There is a "fix" for this, but it's a ZAP only (probably used it before
//MVSIFB10 JOB (0904,0012),GERHARD,CLASS=E
// EXEC SYSZAP,PDS=LPALIB
*
* THIS ZAP BYPASSES THE USELESS IFB010D WTOR (SPECIFY U OR
* IPL REASON - USELESS BECAUSE IT DOES NOT LET YOU
* SPECIFY THE REASON FOR THE IPL)
*
NAME IFBSVC76
VER 0648 0A23 WTOR
VER 064E 4100,0001,0A01 WAIT
*
REP 0648 0700
REP 064E 92E4,9000,0700 REPLY='U'
*

Thanks for the LISTCDS ref Gerhard, appreciated.

About the "REPLY U", I already know I may ZAP in this way, but I prefer to
rename a module (I don't remember now the name or the placement) which
take care of this request once and forever, it should be in the history of
our email lists.

Anyway, this is just a "test system", one of my steps in the direction of
my "New-Moseley".

I want to place as much as I can on 3390 DASDS, next step are RESVOL and
the SMP volumes which shouldn't care at all the DASD type. A couple of
them shouldn't be enough, isn't? One for the DLIBs and the other for the
current system.

Another test I'm going to perform is generating following the Moseley
procedures (almost, I already diverged), but using the Volker TK3 tapes,
as I would like to be near TK4- as much as I can, for when, and I'm
sure I will, I'll be in a bad corner and I'll ask for help.

So, at this very moment, I don't care at all about the "REPLY U"
noise.

By the way, a side question.

Moseley's procedures follow the idea to install as less
as possible from the PTF tape, while Volker's procedures
install as much as possobile.

Ehm ... what the hell, who is right here? ;-)

Thanks, Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, I know I may read the IBM SMP manual, but it is
a bit difficult and I'm a bit lazy these days, after a
rather bad flue.

I hope your chimney gets unclogged soon <G>

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Anyone may help me understanding the JCL needed to list
ACCEPTED and APPLIED PTFS under MVS3.8j?

There is a LISTCDS program on the optional source: CBTCOV.FILE022. I
also have a modified version that doesn't require all the original's
contortion, but I'm not sure where I got it. The ASMTRACE proc is
basically an ASMFCLG with debug support.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
*00 IFB010D ENTER 'IPL REASON,SUBSYSTEM ID' OR 'U'

There is a "fix" for this, but it's a ZAP only (probably used it before
//MVSIFB10 JOB (0904,0012),GERHARD,CLASS=E
// EXEC SYSZAP,PDS=LPALIB
*
* THIS ZAP BYPASSES THE USELESS IFB010D WTOR (SPECIFY U OR
* IPL REASON - USELESS BECAUSE IT DOES NOT LET YOU
* SPECIFY THE REASON FOR THE IPL)
*
NAME IFBSVC76
VER 0648 0A23 WTOR
VER 064E 4100,0001,0A01 WAIT
*
REP 0648 0700
REP 064E 92E4,9000,0700 REPLY='U'
*

Thanks for the LISTCDS ref Gerhard, appreciated.
About the "REPLY U", I already know I may ZAP in this way, but I prefer to
rename a module (I don't remember now the name or the placement) which
take care of this request once and forever, it should be in the history of
our email lists.
Anyway, this is just a "test system", one of my steps in the direction of
my "New-Moseley".
I want to place as much as I can on 3390 DASDS, next step are RESVOL and
the SMP volumes which shouldn't care at all the DASD type. A couple of
them shouldn't be enough, isn't? One for the DLIBs and the other for the
current system.
Another test I'm going to perform is generating following the Moseley
procedures (almost, I already diverged), but using the Volker TK3 tapes,
as I would like to be near TK4- as much as I can, for when, and I'm
sure I will, I'll be in a bad corner and I'll ask for help.
So, at this very moment, I don't care at all about the "REPLY U"
noise.
By the way, a side question.
Moseley's procedures follow the idea to install as less
as possible from the PTF tape, while Volker's procedures
install as much as possobile.
Ehm ... what the hell, who is right here? ;-)
Thanks, Peppe.

And, for "REPLY U", I'm in the SYSGEN phase,
so I may act on the STAGE1 configuration if
I remember corrrectly.

Isn't the CTRLPROG RDE parameter which drive that?

CTLPG CTRLPROG ASCII=INCLUDE, ASCII TRANSLATE ROUTINE C05080003
OPTIONS=(RER, REDUCED ERROR RECOVERY C05090003
DEVSTAT, OFFLINE NOT READY DEVICES AT IPL C05100003
RDE, LOGREC DATA EXTRACTOR C05110003
BLDL), BLDL IN FIXED STORAGE C05120003
SQA=5, # 64K ADDITIONAL SQA BLOCKS C05130003
REAL=128, # 1K V=R BLOCKS C05140003
STORAGE=0, DETERMINE MAX REAL DYNAMICALLY C05150003
WARN=0, IGNORE POWER WARN FEATURE C05160003
ACRCODE=NO, ALTERNATE PROCESSOR RECOVERY C05170003
APFLIB=(SYS1.VTAMLIB,MVSRES, VTAM REQUIRES C05180003
SYS1.INDMAC,MVSRES), IND=YES REQUIRES C05190003
CSA=3072, # 1K BLOCKS CSA C05200003
VRREGN=64, DEFAULT V=R REGION C05210003

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, I know I may read the IBM SMP manual, but it is
a bit difficult and I'm a bit lazy these days, after a
rather bad flue.

I hope your chimney gets unclogged soon <G>

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Anyone may help me understanding the JCL needed to list
ACCEPTED and APPLIED PTFS under MVS3.8j?

There is a LISTCDS program on the optional source: CBTCOV.FILE022. I
also have a modified version that doesn't require all the original's
contortion, but I'm not sure where I got it. The ASMTRACE proc is
basically an ASMFCLG with debug support.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
*00 IFB010D ENTER 'IPL REASON,SUBSYSTEM ID' OR 'U'

There is a "fix" for this, but it's a ZAP only (probably used it before
//MVSIFB10 JOB (0904,0012),GERHARD,CLASS=E
// EXEC SYSZAP,PDS=LPALIB
*
* THIS ZAP BYPASSES THE USELESS IFB010D WTOR (SPECIFY U OR
* IPL REASON - USELESS BECAUSE IT DOES NOT LET YOU
* SPECIFY THE REASON FOR THE IPL)
*
NAME IFBSVC76
VER 0648 0A23 WTOR
VER 064E 4100,0001,0A01 WAIT
*
REP 0648 0700
REP 064E 92E4,9000,0700 REPLY='U'
*

Thanks for the LISTCDS ref Gerhard, appreciated.
About the "REPLY U", I already know I may ZAP in this way, but I prefer to
rename a module (I don't remember now the name or the placement) which
take care of this request once and forever, it should be in the history of
our email lists.
Anyway, this is just a "test system", one of my steps in the direction of
my "New-Moseley".
I want to place as much as I can on 3390 DASDS, next step are RESVOL and
the SMP volumes which shouldn't care at all the DASD type. A couple of
them shouldn't be enough, isn't? One for the DLIBs and the other for the
current system.
Another test I'm going to perform is generating following the Moseley
procedures (almost, I already diverged), but using the Volker TK3 tapes,
as I would like to be near TK4- as much as I can, for when, and I'm
sure I will, I'll be in a bad corner and I'll ask for help.
So, at this very moment, I don't care at all about the "REPLY U"
noise.
By the way, a side question.
Moseley's procedures follow the idea to install as less
as possible from the PTF tape, while Volker's procedures
install as much as possobile.
Ehm ... what the hell, who is right here? ;-)
Thanks, Peppe.

And, for "REPLY U", I'm in the SYSGEN phase,
so I may act on the STAGE1 configuration if
I remember corrrectly.
Isn't the CTRLPROG RDE parameter which drive that?
CTLPG CTRLPROG ASCII=INCLUDE, ASCII TRANSLATE ROUTINE C05080003
OPTIONS=(RER, REDUCED ERROR RECOVERY C05090003
DEVSTAT, OFFLINE NOT READY DEVICES AT IPL C05100003
RDE, LOGREC DATA EXTRACTOR C05110003
BLDL), BLDL IN FIXED STORAGE C05120003
SQA=5, # 64K ADDITIONAL SQA BLOCKS C05130003
REAL=128, # 1K V=R BLOCKS C05140003
STORAGE=0, DETERMINE MAX REAL DYNAMICALLY C05150003
WARN=0, IGNORE POWER WARN FEATURE C05160003
ACRCODE=NO, ALTERNATE PROCESSOR RECOVERY C05170003
APFLIB=(SYS1.VTAMLIB,MVSRES, VTAM REQUIRES C05180003
SYS1.INDMAC,MVSRES), IND=YES REQUIRES C05190003
CSA=3072, # 1K BLOCKS CSA C05200003
VRREGN=64, DEFAULT V=R REGION C05210003
Peppe.

Yep, it is RDE, from a discussion we had in the h390-mvs list,
for who is interested, around July 2016.

That is an option, but I'm not sure about what I would loose
not coding the RDE, as the IBM manual report:

"specifies inclusion of the reliability data extractor
feature"

Mmm ... perhapes LOGREC would be lost not coding RDE in SYSGEN?

From the other side, this simple trick (source Thomas Armostrong,
already tested):

Hi Peppe,The easiest way to prevent the unwanted message from appearing is to
rename module IFCRDE03 in SYS1.LINKLIB to some other name. That way you
can toggle themessage on or off without a CLPA IPL. IFBSVC76 uses the presence or
absence of IFCRDE03 in LINKLIB as a test if the system was genned with the
RDE option.

allow to turn on/off this feature, at runtime, without any
needs for a ZAP or a SYSGEN.

Better isn't?

Peppe.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
From the other side, this simple trick (source Thomas Armostrong,

Hi Peppe,The easiest way to prevent the unwanted message from appearing is to
rename module IFCRDE03 in SYS1.LINKLIB to some other name. That way you
can toggle themessage on or off without a CLPA IPL. IFBSVC76 uses the presence or
absence of IFCRDE03 in LINKLIB as a test if the system was genned with the
RDE option.
allow to turn on/off this feature, at runtime, without any
needs for a ZAP or a SYSGEN.
Better isn't?

The message never appears in tk3 (I don't know about tk4-), because it
is automatically replied to by IEECVXIT. When you start from scratch,
you're presumably missing all the customization in there.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
From the other side, this simple trick (source Thomas Armostrong,

Hi Peppe,The easiest way to prevent the unwanted message from appearing is to
rename module IFCRDE03 in SYS1.LINKLIB to some other name. That way you
can toggle themessage on or off without a CLPA IPL. IFBSVC76 uses the presence or
absence of IFCRDE03 in LINKLIB as a test if the system was genned with the
RDE option.
allow to turn on/off this feature, at runtime, without any
needs for a ZAP or a SYSGEN.
Better isn't?

The message never appears in tk3 (I don't know about tk4-), because it
is automatically replied to by IEECVXIT. When you start from scratch,
you're presumably missing all the customization in there.

Let call this "REPLY U" issue the "infamous IFB010D message issue" ;-)

TK4-, for what I may read in its SYS1.SYSGEN(IOGEN) hasn't
the RDE parm in its CTLPG, so, doesn't even issue the message.

And TK4-, I guess, inherits this "missing feature" from TK3 Volker's
SYSGEN, check Volker's original sg0160 SYSGEN JCL:

CTLPG CTRLPROG ACRCODE=YES, (NO for UP) Alternate Processor Recovery+
APFLIB=(SYS1.VTAMLIB,MVSRES, required for VTAM +
SYS1.INDMAC,MVSRES), required for IND=YES +
ASCII=INCLUDE, We do want ASCII suppot +
CSA=2048, 2MB for CSA, please +
OPTIONS=(BLDL, Make BLDL in real storage +
DEVSTAT, make non-ready devs offline +
RER), allow reduced err recov. +
REAL=128, Max size for V=R region +
SQA=3, Increase SQA by 3 seqments +
STORAGE=0, Find real storage amount +
TZ=(E,1), One hour east of GMT +
WARN=0 No Power warning feature

There is not any RDE in its CTLPG, while Jay Moseley "sysgen01.jcl"
has it:

CTLPG CTRLPROG ASCII=INCLUDE, ASCII TRANSLATE ROUTINE C05080003
OPTIONS=(RER, REDUCED ERROR RECOVERY C05090003
DEVSTAT, OFFLINE NOT READY DEVICES AT IPL C05100003
RDE, LOGREC DATA EXTRACTOR C05110003
BLDL), BLDL IN FIXED STORAGE C05120003
SQA=5, # 64K ADDITIONAL SQA BLOCKS C05130003
REAL=128, # 1K V=R BLOCKS C05140003
STORAGE=0, DETERMINE MAX REAL DYNAMICALLY C05150003
WARN=0, IGNORE POWER WARN FEATURE C05160003
ACRCODE=NO, ALTERNATE PROCESSOR RECOVERY C05170003
APFLIB=(SYS1.VTAMLIB,MVSRES, VTAM REQUIRES C05180003
SYS1.INDMAC,MVSRES), IND=YES REQUIRES C05190003
CSA=3072, # 1K BLOCKS CSA C05200003
VRREGN=64, DEFAULT V=R REGION C05210003
TZ=(W,5) ONE HOUR WEST OF GMT 05220003

I guess we solved this issue, Gerhard?

From the other side the Thomas post is clear enough.

The are two main roads:

1) use RDE in CTLPG and control message IFB010D using the presence of the
IFCRDE03 module in SYS1.LINKLIB, let call it the "Moseley way";

2) don't use RDE in CTLPG, actually preventing any future
use of this feature, without a new SYSGEN, let call it
the "Volker way".

I prefer the first, I've a "feature" which may easily be
controlled with this simple JCL template, using IEHPROGM
IBM utility:

//IFCRDE03 JOB (IFCRDE03),'IFCRDE03',
// CLASS=A,MSGLEVEL=(1,1),MSGCLASS=A
//*
//*********************************************************************
//* rename PEP380:SYS1.LINKLIB(IFCRDE03) for "REPLY U" 10/11/2017
//*********************************************************************
//*
//IEHPROGM EXEC PGM=IEHPROGM
//SYSPRINT DD SYSOUT=*
//DD1 DD VOL=SER=PEP380,DISP=SHR,UNIT=3380
//SYSIN DD *
RENAME DSNAME=SYS1.LINKLIB,VOL=3380=PEP380, C
MEMBER=IFCRDE03,NEWNAME=IFCRDEX3
//*
//

What do you prefer, Gerhard?

Peppe.

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

By the way, a side note.

I'm learning more things about MVS3.8j installation
comparing the "Volker way" with the "Moseley way" than
I learned in the past few years I get involved in this
topic.

I've this strong feeling that "most" MVS3.8j users went
almost "blindly" behind Volker's TK3 setup, so a lot
of the "degrees of freedom" IBM left for MVS3.8j installation
and configuration has been "forgotten", just because they haven't been
discussed for "years", if not for "decades".

The recent accident about JES2 printer/punch configuration
is just an example, I guess, and another example
is the "IFB010D issue".

Isn't time for a new MVS3.8j setup?

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Isn't time for a new MVS3.8j setup?

Given that MVS/380 is permanently out-of-date
compared to TK4-, and given that I'm not aware
of anyone using it for anything other than
building software using 31-bit GCCMVS, maybe
I should build MVS/380 on top of your build so
that it actually gets used/tested?

This would also solve another problem - I am
not sure what portion of TK4- is copyrighted.
I can remember seeing copyright notices from
Volker, which is why I preferred distributing
MVS/380 as shadow files. But Scott seems
to have been brave enough to combine the
two products.

You weren't around during the TK3SU1 debacle
where Phil decided to start asserting copyright
over that freeware. So yeah, it would be good
if you could ensure that everything goes into
your build on top of the original IBM tapes has
an explicit "released to the public domain"
notice, something that TK3SU1 didn't have that
I could point to.

Although I fully intend to install GCCMVS on it,
which is copyrighted freeware. So I'm not sure
what the rule should be. In the very long term
I would like pure PD software, but that is not
practical at the moment.

But I don't want to see some poor company
sued for using MVS/380 because of a repeat
of TK3SU1.

BFN. Paul.

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

Post by ***@yahoo.com.au [hercules-os380]
I can remember seeing copyright notices from
Volker,

And some months ago in the turnkey group
I explicitly requested Volker to release all
his work to the public domain, because
Gerhard had balked at even changing a
broken vertical bar to a solid bar because
of copyright issues, and I received no
reply which, after TK3SU1, makes me
real leery.

I can't guess who is unexpectedly going to
start asserting copyright, and without an
explicit public domain notice to point to,
that makes things very difficult indeed
in court.

There is even some doubt about the
status of IBM's MVS 3.8j, but I personally
think we're safe with that. But IBM refuses
to put something in writing to confirm that
it is public domain. There is folklore that
IBM did that with MVT, but no folklore on
MVS - quite the reverse.

All of which makes me a bit leery. I have
hedged my bets somewhat by creating
PDOS/3x0, which solves two more
problems - out-of-date source and source
in unmaintainable assembler instead of C.

BFN. Paul.

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

https://en.wikipedia.org/wiki/Software_copyright
Until 1980, software was not copyrightable, so it was all in the public domain.
Until IBM started the XA migration with MVS/SP there wasn't enough
change to apply copyright to MVS 3.8 or before.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Isn't time for a new MVS3.8j setup?

Given that MVS/380 is permanently out-of-date
compared to TK4-, and given that I'm not aware
of anyone using it for anything other than
building software using 31-bit GCCMVS, maybe
I should build MVS/380 on top of your build so
that it actually gets used/tested?
This would also solve another problem - I am
not sure what portion of TK4- is copyrighted.
I can remember seeing copyright notices from
Volker, which is why I preferred distributing
MVS/380 as shadow files. But Scott seems
to have been brave enough to combine the
two products.
You weren't around during the TK3SU1 debacle
where Phil decided to start asserting copyright
over that freeware. So yeah, it would be good
if you could ensure that everything goes into
your build on top of the original IBM tapes has
an explicit "released to the public domain"
notice, something that TK3SU1 didn't have that
I could point to.
Although I fully intend to install GCCMVS on it,
which is copyrighted freeware. So I'm not sure
what the rule should be. In the very long term
I would like pure PD software, but that is not
practical at the moment.
But I don't want to see some poor company
sued for using MVS/380 because of a repeat
of TK3SU1.
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

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

Post by Mike Schwab ***@gmail.com [hercules-os380]
https://en.wikipedia.org/wiki/Software_copyright

I checked that link.

Post by Mike Schwab ***@gmail.com [hercules-os380]
Until 1980, software was not copyrightable,
so it was all in the public domain.

I disagree that that is the only interpretation
of that article.

E.g. there is this statement:

In 1974, the Commission on New Technological Uses of Copyrighted Works (CONTU) was established. CONTU decided that "computer programs, to the extent that they embody an author's original creation, are proper subject matter of copyright".

Post by Mike Schwab ***@gmail.com [hercules-os380]
Until IBM started the XA migration with
MVS/SP there wasn't enough
change to apply copyright to MVS 3.8 or before.

I don't agree that that is clear-cut either.

There is prior art, e.g. TK3SU1, of people
trying to assert copyright over material long
after it was publicly released.

Without an explicit PD notice, only a court
can decide the matter, and I have no faith
at all in any country's justice system.

We also have the fact that IBM refuses to
state on the record that MVS 3.8j is public
domain and can be used freely.

Like I said, I *think* we are safe, but I'm
hedging my bets at the same time. What
I *think* may not actually be correct, and
I fully expect that different courts and
different countries would rule differently.

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Mike Schwab ***@gmail.com [hercules-os380]
https://en.wikipedia.org/wiki/Software_copyright
Until 1980, software was not copyrightable, so it was all in the public domain.
Until IBM started the XA migration with MVS/SP there wasn't enough
change to apply copyright to MVS 3.8 or before.

That's something I'm ashamed of; I worked at Applied Data Research from
1966 until 1971. One of the founders, Marty Goetz, sued twice on
software related issues. The earlier suit was to get a patent on
software, on the justification that the program (a SORT) controlled the
hardware in a novel way, etc., etc.

The second suit, somewhat later, came after ADR developed ROSCOE, and
claimed that IBM was anti-competitive by giving away free copies of CRBE
(and perhaps CRJE). The copyright issue was part of that. The suit was
settled, and IBM let itself be "forced" to start charging for software
(other than the "minimum" system code needed to use the hardware).

As to MVS, prior to a copyright revision (mid to late seventies?) a work
could be copyrighted only if it had an explicit "COPYRIGHT yyyy, owner",
and a sample was submitted with a copyright application. After the
revision, any original work was considered to have a copyright, even in
the absence of such a notice. The only caveat was that a copyright had
to be applied for, and granted, before the owner could sue for a
violation (hence Phil may have been legally within his rights).

This is a good reason for Paul to insist on a explicit Public Domain
statement in the code.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
and a sample was submitted with a copyright application. After the
revision, any original work was considered to have a copyright, even in
the absence of such a notice. The only caveat was that a copyright had
to be applied for, and granted, before the owner could sue for a
violation (hence Phil may have been legally within his rights).

And IIRC, Phil was investigating what he
needed to do to register the copyright so
that he could indeed sue me.

I'm not sure how he thought he could
extradite me though.

The whole thing was dropped after the
MVS/380 technology had moved on and
was dependent on a different one of
Phil's distributions, which to date he
hasn't issued any threats about.

But if MVS/380 2.0 is built on a Peppe
distribution, and Peppe has an explicit
PD notice, then that may be a better
way forward, especially if we look
closer at the MVS/380 2.0 audience.
As far as I know, I'm the main user of
it, and I only ever run it for a few
seconds or a few minutes, automatically,
to do some software build, the result of
which can then be taken to TK4- or z/OS,
as you wish. Occasionally I log on to
TSO to check something.

If MVS/380 3.0 allows 64-bit programming
and that is enough to trigger someone to
be able to make commercial use of it, what
will their requirements be? I'd guess their
number one requirement would be to make
sure that they are not violating any copyright,
and installing tons of software is their
second requirement. I would guess they
really want things like Wally's ISPF, but I'm
not familiar with the copyright status of that.
Having to install all that software themselves
would be a good reason for them to go the
TK4- path instead of MVS/380 though, if
they can be confident about the copyright
status.

I'm not really sure what the best approach
is, but fortunately I don't have to deal with
that at the moment, as my focus is still on
PDPCLIB development and the MVS/380
technology itself, rather than the presence
or absence of tons of software. I will need
all those 64-bit macros though. In fact, I'm
surprised those 64-bit macros exist at all.
Who are they actually for? z/OS already
comes with an assembler supporting
64-bit instructions, and Hercules/380 only
recently supported 64-bit instructions for
use by MVS 3.8j. Who else can use them?

BFN. Paul.

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

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
The second suit, somewhat later, came after ADR developed ROSCOE, and
claimed that IBM was anti-competitive by giving away free copies of CRBE
(and perhaps CRJE). The copyright issue was part of that. The suit was
settled, and IBM let itself be "forced" to start charging for software
(other than the "minimum" system code needed to use the hardware).

ADR is not necessarily wrong for
doing that. The status of (subsidized)
freeware from IBM, or GPL code
distorting the free market, is something
that I think needs to be addressed.

It depends what you see as ideally
happening under the capitalist
system. It is not wrong for a business
to make an initial loss, but they should
be trying to turn a profit. If they're not
trying to turn a profit, I'd be real
suspicious of where the money is
coming from. Money laundering?

I'll have to reply to those recent
messages in turnkey-mvs. I have
been too focused on writing code. :-)

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
ADR is not necessarily wrong for
doing that. The status of (subsidized)
freeware from IBM, or GPL code
distorting the free market, is something
that I think needs to be addressed.

Would you buy a modern car if you had to pay for the software that
monitors status and reliability, or pay extra to have the built-in GPS
work? I consider IBM to be right in supplying a free operating system
with your hardware. The business model here is that you pay extra for
optional components, or system features that are superior to the free
version.

Post by ***@yahoo.com.au [hercules-os380]
It depends what you see as ideally
happening under the capitalist
system. It is not wrong for a business
to make an initial loss, but they should
be trying to turn a profit. If they're not
trying to turn a profit, I'd be real
suspicious of where the money is
coming from. Money laundering?

The capitalist system is inherently flawed, unless laws are passed and
enforced to prevent cartels, selling at a loss to drive competition out
of business, and other "brilliant" shenanigans. It's been said that a
benign dictatorship provides the best government, with the caveat that
it doesn't stay that way.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
ADR is not necessarily wrong for
doing that. The status of (subsidized)
freeware from IBM, or GPL code
distorting the free market, is something
that I think needs to be addressed.

Would you buy a modern car if you had to pay for the software that
monitors status and reliability,

Unless they are using freeware, I do indeed
pay for the software already.

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
or pay extra to have the built-in GPS work?

If GPS is an option, then yes, I choose to buy
both the hardware and software.

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
I consider IBM to be right in supplying a free operating system
with your hardware.

It's "free" in exchange for "millions of dollars".

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
The business model here is that you pay extra for
optional components, or system features that are superior to the free
version.

No, it is being incorporated into the cost
of the hardware, which is quite strange,
as it means that a competitor such as
Amdahl can sell the hardware and let
IBM pay for the software. That's
ridiculous for IBM.

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
The capitalist system is inherently flawed, unless laws are passed and
enforced to prevent cartels, selling at a loss to drive competition out
of business, and other "brilliant" shenanigans.

I don't mind tempering capitalism to deal
with such flaws.

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
It's been said that a
benign dictatorship provides the best government,
with the caveat that
it doesn't stay that way.

I don't see how a benign dictator can do a
better job than a democracy about exactly
how to temper capitalism. It's not like there's
a definite way of dealing with this problem,
but for some reason no democracy in the
world is willing to let their politicians do it,
even when those elected politicians have
considerable scope to implement some
unpopular things.

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Isn't time for a new MVS3.8j setup?

Given that MVS/380 is permanently out-of-date
compared to TK4-, and given that I'm not aware
of anyone using it for anything other than
building software using 31-bit GCCMVS, maybe
I should build MVS/380 on top of your build so
that it actually gets used/tested?

This would also solve another problem - I am
not sure what portion of TK4- is copyrighted.
I can remember seeing copyright notices from
Volker, which is why I preferred distributing
MVS/380 as shadow files. But Scott seems
to have been brave enough to combine the
two products.

You weren't around during the TK3SU1 debacle
where Phil decided to start asserting copyright
over that freeware. So yeah, it would be good
if you could ensure that everything goes into
your build on top of the original IBM tapes has
an explicit "released to the public domain"
notice, something that TK3SU1 didn't have that
I could point to.

Although I fully intend to install GCCMVS on it,
which is copyrighted freeware. So I'm not sure
what the rule should be. In the very long term
I would like pure PD software, but that is not
practical at the moment.

But I don't want to see some poor company
sued for using MVS/380 because of a repeat
of TK3SU1.

BFN. Paul.

---

Paul, my question, and it is a question,
not a proposal, was directed with people
with far more MVS experience than me.

I'm just a beginner as MVS "sysadm" (I know
this is not the term used in the mainframe
world ;-) ) and I'm pretty sure my MVS SYSGEN
it is as naive as it is possible.

From the other side, I can't even picture Juergen
or Volker may even picture to "copyright" their
TK3/TK4- MVS SYSGEN. For what?

I'm just happy to have the occasion of learning
from MVS people as much as I can, for what I
consider a pleasant hobby, at my age (I'm sixty
this year, I'll be retired in about five years).

But my question is still here, waiting for answers ;-)

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
world ;-) ) and I'm pretty sure my MVS SYSGEN
it is as naive as it is possible.

If you're the only one supporting 3390
disks, it sounds like you are creating
the most sophisticated sysgen.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
From the other side, I can't even picture Juergen
or Volker may even picture to "copyright" their
TK3/TK4- MVS SYSGEN. For what?

Prior to Phil, I couldn't picture anyone
claiming copyright over freeware they
had already released. I take precautions
because of what is technically possible.

I can remember someone, a Swede I
think, who was advocating joining NATO,
and he was asked what the point of that
is, given the end of the Cold War.

And his reply was that he had no idea.
He couldn't predict the future. What he
did know though, was that in the past,
people had predicted both peace and
war and been horribly wrong. And that
when the Berlin wall was being torn
down, no-one at all said "uh oh, bloodbath
in Yugoslavia".

NATO membership protects against things
you don't know about.

Public domain notices protect against things
you can't predict either. Phil and I used to
cooperate. GCCMVS either wouldn't exist,
or it would have been significantly delayed,
without Phil's assistance.

As far as I know, very little, if any, of the code
that went into TK3SU1 was written by Phil.
But when the shit hit the fan he was quoting
copyright law saying that he had the right
to copyright just the building of the package,
even if he didn't own the contents.

Does a SYSGEN count as copyright? Without
an explicit PD notice, only a court can decide.

I don't want to go to courts, which I don't trust
one iota. I want it settled with an explicit PD
notice before it goes to court.

Do I think that you or Volker or Juergen would
suddenly claim copyright of your sysgen and
threaten me with legal action? Of course not.
It would be totally absurd for a freeware author
to do something like that. This is a small
community. The chances of this rare event
happening to anyone I know must be close
to zero.

The Yugoslav/Phil bloodbath happened anyway.

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
world ;-) ) and I'm pretty sure my MVS SYSGEN
it is as naive as it is possible.

If you're the only one supporting 3390
disks, it sounds like you are creating
the most sophisticated sysgen.

---

I'm still far from "supporting" 3390.

I'm just happy I may logon to the TSO of
a rather "incomplete" MVS3.8j which it
happens to IPL from a 3380 (still to test
a 3390).

By the way, my "3380-SYSGEN" is broadly
a modified copy of the Moseley SYSGEN.

If Jay Moseley ask for a copyright on
his code, well ... you would be in trouble
trying to make money from such a code, Paul.

By the way, who on the hell may make money
from an OS of seventies?

I would be glad to meet such a people ;-)

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, my "3380-SYSGEN" is broadly
a modified copy of the Moseley SYSGEN.
If Jay Moseley ask for a copyright on
his code, well ... you would be in trouble
trying to make money from such a code, Paul.

In that case it would be good if you started
from the IBM-provided sysgen code instead,
which presumably exists. Or ask Jay if his
modifications are public domain (if you can
detect he has made any modifications).

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, who on the hell may make money
from an OS of seventies?
I would be glad to meet such a people ;-)

And I'd like to meet the 200,000 people
killed in Bosnia due to the Cold War ending.

Regardless, here is someone else's comment:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/1828

I think that MVS/380 could very well be disruptive technology given a capable COBOL compiler, KICKS and let's say a port of PostGreSQL running as a STC.


Since then we have invented and implemented
64-bit instructions, we have invented but not
really implemented properly access to ATB
memory, we have invented but not implemented
"separate memory" for protected ATL memory,
we have implemented but not released multiple
ATL memory access, implemented but not
released AMODE honoring in IEWFETCH, we
have implemented but not released ANY/ANY
modules, designed but not implemented trimodal
modules, we have implemented but not released
(currently slated for MVS/380 2.1) some 31-bit
clean I/O routines allowing fully-31bit (not
bimodal) applications like REVIEW to access ATL
memory the same as they can on OS/390 and
abvove, and any patents related to z/Arch 1.0
are due to expire at the end of 2021, ie 4 years
from now, during which time I expect all those
"not released" will turn into "released".

Also note that as far as Cobol compilers go,
GNU Cobol exists, but I don't know of anyone
who has attempted to use it to build a Cobol
application on MVS/380. Given that it
supposedly generates C code, it may be
possible, even if you can't run GNU Cobol
natively like you can GCCMVS. Some people
think it's better to run non-native anyway.
Compiles are certainly faster non-native.

And although no-one has reported having
ported PostGreSQL, there have been 2
people who seemed to suggest they might
have a go at SQLite, which has a pretty
good chance of working on JCC, given
that Jason actually produced an SQLite
patch suggesting that he already got it
to work and just didn't want to release any
binaries.

BFN. Paul.

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

above, and any patents related to z/Arch 1.0
are due to expire at the end of 2021, ie 4 years
from now,

Actually the z/Arch SA22-7832-00 POP
was released in December 2000, so
I assume we're just 3 years away from
patent expiry.

during which time I expect all those
"not released" will turn into "released".

Note that I didn't mean to imply that we
were waiting for the patents to expire
before releasing the software.

Also note that neither MVS/380 nor
the Hercules hardware, nor the underlying
real hardware, nor GCCMVS, are
"from the 70s", even though *both* z/OS
and MVS/380 are indeed based on an OS
"from the 70s", and that is actually a good
thing for upward compatibility that doesn't
exist on something like Linux. Even my
Windows 10 doesn't let me run simple
(not system-related) MSDOS modules from
the early 1990s. :-(

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, my "3380-SYSGEN" is broadly
a modified copy of the Moseley SYSGEN.
If Jay Moseley ask for a copyright on
his code, well ... you would be in trouble
trying to make money from such a code, Paul.

In that case it would be good if you started
from the IBM-provided sysgen code instead,
which presumably exists. Or ask Jay if his
modifications are public domain (if you can
detect he has made any modifications).

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, who on the hell may make money
from an OS of seventies?
I would be glad to meet such a people ;-)

And I'd like to meet the 200,000 people
killed in Bosnia due to the Cold War ending.

Regardless, here is someone else's comment:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/1828

I think that MVS/380 could very well be disruptive technology given a capable COBOL compiler, KICKS and let's say a port of PostGreSQL running as a STC.


Since then we have invented and implemented
64-bit instructions, we have invented but not
really implemented properly access to ATB
memory, we have invented but not implemented
"separate memory" for protected ATL memory,
we have implemented but not released multiple
ATL memory access, implemented but not
released AMODE honoring in IEWFETCH, we
have implemented but not released ANY/ANY
modules, designed but not implemented trimodal
modules, we have implemented but not released
(currently slated for MVS/380 2.1) some 31-bit
clean I/O routines allowing fully-31bit (not
bimodal) applications like REVIEW to access ATL
memory the same as they can on OS/390 and
abvove, and any patents related to z/Arch 1.0
are due to expire at the end of 2021, ie 4 years
from now, during which time I expect all those
"not released" will turn into "released".

Also note that as far as Cobol compilers go,
GNU Cobol exists, but I don't know of anyone
who has attempted to use it to build a Cobol
application on MVS/380. Given that it
supposedly generates C code, it may be
possible, even if you can't run GNU Cobol
natively like you can GCCMVS. Some people
think it's better to run non-native anyway.
Compiles are certainly faster non-native.

And although no-one has reported having
ported PostGreSQL, there have been 2
people who seemed to suggest they might
have a go at SQLite, which has a pretty
good chance of working on JCC, given
that Jason actually produced an SQLite
patch suggesting that he already got it
to work and just didn't want to release any
binaries.

BFN. Paul.

---

Paul, I'm having a real "good time" with
MVS3.8j and GCCMVS.

Porting codes from the UNIX world to MVS
is a rather pleasant thing to do for
a C programmer, as I had been in the past ;-)

But, I'm rather skepical about any possibility
of getting out money from what I just consider
an hobby for my "retirement time", which is
just to come.

I'm wishing you all the possible luck, Paul,
but if you think to make money from MVS3.8j,
in any new shape you may be able to give it,
you need something more than a "good luck".

We live today in a world of large datacenters,
geographically distributed datacenters, installed
on thousands of racks, with petabytes orders
SAN, where virtualization of OS and Networking
is the ruling master.

People at CERN, the same people who found
"The Higgs", with LHC, are discussing in
these days, here, in a side Physics Department,
about the possibility to transfer their HPC
jobs from the hardware they own to virtual
clusters running on cloud virtalized hardware.

They are going to use "docks", puppet, maas
etc, a mess of python undebuggable code, to
install and control their virtual hardware
on objects like OpenStack.

Well, MVS3.8j is simply too old ;-)

I'm simply too old ;-)

Good my retirement horizon is not such far.

I'll be glad, in such an age, to come back
from the role of sysadm to the role of user
playing with hercules emulator on his own
workstation ;-)

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, who on the hell may make money
from an OS of seventies?
I would be glad to meet such a people ;-)

1) A significant part of IBM's current z/OS is unchanged or nearly so
from their 1970s OSs.
2) IBM continues to make money from non-OS programs developed in the
1970s, and barely changed since then. For example the current High
Level Assembler (HLASM) is essentially Assembler H from around 1970,
updated certainly, but not very much. And a significant part of the
updates came from changes made at Stanford University in the 1980s and
given to IBM.
Tony H.

Tony, I was speaking specifically of MVS3.8j. While most of
its applications would run unchanged under z/OS, this do
not imply anyone may be able to make money out of this
particular version of an OS, from the seventies, especially
if attempted outside IBM.

Am I wrong, Tony?

Peppe.

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

Over the years, we have seen people migrate their out of support
mainframes to hercules. At least one person installed turnkey 3 to
teach a cobol class.

On Tue, Nov 14, 2017 at 3:17 AM, Giuseppe Vitillaro

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, who on the hell may make money
from an OS of seventies?
I would be glad to meet such a people ;-)

1) A significant part of IBM's current z/OS is unchanged or nearly so
from their 1970s OSs.
2) IBM continues to make money from non-OS programs developed in the
1970s, and barely changed since then. For example the current High
Level Assembler (HLASM) is essentially Assembler H from around 1970,
updated certainly, but not very much. And a significant part of the
updates came from changes made at Stanford University in the 1980s and
given to IBM.
Tony H.

Tony, I was speaking specifically of MVS3.8j. While most of
its applications would run unchanged under z/OS, this do
not imply anyone may be able to make money out of this
particular version of an OS, from the seventies, especially
if attempted outside IBM.
Am I wrong, Tony?
Peppe.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

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

Well, we have a market ;-)

Peppe.

Post by Mike Schwab ***@gmail.com [hercules-os380]
Over the years, we have seen people migrate their out of support
mainframes to hercules. At least one person installed turnkey 3 to
teach a cobol class.
On Tue, Nov 14, 2017 at 3:17 AM, Giuseppe Vitillaro

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, who on the hell may make money
from an OS of seventies?
I would be glad to meet such a people ;-)

1) A significant part of IBM's current z/OS is unchanged or nearly so
from their 1970s OSs.
2) IBM continues to make money from non-OS programs developed in the
1970s, and barely changed since then. For example the current High
Level Assembler (HLASM) is essentially Assembler H from around 1970,
updated certainly, but not very much. And a significant part of the
updates came from changes made at Stanford University in the 1980s and
given to IBM.
Tony H.

Tony, I was speaking specifically of MVS3.8j. While most of
its applications would run unchanged under z/OS, this do
not imply anyone may be able to make money out of this
particular version of an OS, from the seventies, especially
if attempted outside IBM.
Am I wrong, Tony?
Peppe.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Tony Harminc [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Tony, I was speaking specifically of MVS3.8j. While most of
its applications would run unchanged under z/OS, this do
not imply anyone may be able to make money out of this
particular version of an OS, from the seventies, especially
if attempted outside IBM.
Am I wrong, Tony?

Well I don't know if you're wrong... Has anyone tried and succeeded
(or conspicuously failed)?

There is at least one person who seems to make a little money by
selling CDs on eBay containing Hercules packaged with MVS 3.8j. But I
imagine that's not what you mean.

Tony H.

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

Post by Tony Harminc ***@gmail.com [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Tony, I was speaking specifically of MVS3.8j. While most of
its applications would run unchanged under z/OS, this do
not imply anyone may be able to make money out of this
particular version of an OS, from the seventies, especially
if attempted outside IBM.
Am I wrong, Tony?

Well I don't know if you're wrong... Has anyone tried and succeeded
(or conspicuously failed)?
There is at least one person who seems to make a little money by
selling CDs on eBay containing Hercules packaged with MVS 3.8j. But I
imagine that's not what you mean.
Tony H.

For sure it is not what Paul means :-)

I stay with my feeling that playing with MVS3.8j is
just an hobby, for people like me which doesn't have
any legal access to z/OS ... :-)

Peppe.

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

And we helped a high school drop out taking community college classes
https://twitter.com/ConnorKrukosky?lang=en configure his $300.00 12
years old z800 into a job with IBM testing a z14 before it was
announced, a class A motor home, a sticks and bricks (house) with
skills training. What you learn on MVS 3.8 still applied to z/OS.
Yes, it is old, but once you learn the basics the new stuff on modern
hardware software is just icing on the cake.

On Tue, Nov 14, 2017 at 12:25 PM, Giuseppe Vitillaro

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Tony Harminc ***@gmail.com [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Tony, I was speaking specifically of MVS3.8j. While most of
its applications would run unchanged under z/OS, this do
not imply anyone may be able to make money out of this
particular version of an OS, from the seventies, especially
if attempted outside IBM.
Am I wrong, Tony?

Well I don't know if you're wrong... Has anyone tried and succeeded
(or conspicuously failed)?
There is at least one person who seems to make a little money by
selling CDs on eBay containing Hercules packaged with MVS 3.8j. But I
imagine that's not what you mean.
Tony H.

For sure it is not what Paul means :-)
I stay with my feeling that playing with MVS3.8j is
just an hobby, for people like me which doesn't have
any legal access to z/OS ... :-)
Peppe.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

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

I'm probably boring the list, but I like to post,
as a future reference, my analysis on the differences
between Volker/TK3 and Moseley SMP/DLIB, in their respective
SYSGEN.

I just tested the Volker tapes using the Moseley JCL
streams, to create DLIB SMP volumes, in the Volker style
(MVSBLB,SMP001,SMP002,SMP003,SMP004), with Volker datasets
allocation.

The only difference I can see in the way the DLIB are built
in Volker sg0070 and Moseley smpjob03.jcl, beside the
tape labels and format, are these two PTFS (UZ68825 UZ71903)

EDS1102 UZ68825 UZ71903 /* DM Support */

which Volker installs and Moseley doesn't.

Please correct me if my eyes are missing important
details on this quite important, I think, point.

The JCL I've written, modeled on the Moseley way, does
the job for the Volker tapes (and PTFS) without any
evident problem and with just some minor modification
(basically tape names and format, plus that EDS1102 couple of PTFS).

I had been able to SYSGEN a new 3350 MVS RESVOL using these
DLIBs (Volker-tapes-PTF built), again in the Moseley style.

That RESVOL, for what I may test right now (no VTAM/TSO),
IPL and start JES2 without any evident difference.

I'll try to SYSGEN a 3380/3390 new RESVOL, from that system
to test this weird system, an hybrid Volker-Moseley ;-) ... which,
I guess, has never been installed until now?

Peppe.

[Joe Monk [e-mail] [hercules-os380]]

Peppe,

Ive noticed a big difference...

If you compare the zdlibs1 tape from volker and the product.het tape from
moseley, you will find the moseley tape is about 2 MB larger. That, of
course, means that the moseley tapes have more products...

I'm currently exploring to see what the differences are between the two.

Joe

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I'm probably boring the list, but I like to post,
as a future reference, my analysis on the differences
between Volker/TK3 and Moseley SMP/DLIB, in their respective
SYSGEN.
I just tested the Volker tapes using the Moseley JCL
streams, to create DLIB SMP volumes, in the Volker style
(MVSBLB,SMP001,SMP002,SMP003,SMP004), with Volker datasets
allocation.
The only difference I can see in the way the DLIB are built
in Volker sg0070 and Moseley smpjob03.jcl, beside the
tape labels and format, are these two PTFS (UZ68825 UZ71903)
EDS1102 UZ68825 UZ71903 /* DM Support */
which Volker installs and Moseley doesn't.
Please correct me if my eyes are missing important
details on this quite important, I think, point.
The JCL I've written, modeled on the Moseley way, does
the job for the Volker tapes (and PTFS) without any
evident problem and with just some minor modification
(basically tape names and format, plus that EDS1102 couple of PTFS).
I had been able to SYSGEN a new 3350 MVS RESVOL using these
DLIBs (Volker-tapes-PTF built), again in the Moseley style.
That RESVOL, for what I may test right now (no VTAM/TSO),
IPL and start JES2 without any evident difference.
I'll try to SYSGEN a 3380/3390 new RESVOL, from that system
to test this weird system, an hybrid Volker-Moseley ;-) ... which,
I guess, has never been installed until now?
Peppe.

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

Post by Joe Monk ***@gmail.com [hercules-os380]
Peppe,
Ive noticed a big difference...
If you compare the zdlibs1 tape from volker and the product.het tape from
moseley, you will find the moseley tape is about 2 MB larger. That, of
course, means that the moseley tapes have more products...
I'm currently exploring to see what the differences are between the two.
Joe

Yep, Joe, I noticed that difference.

But I can't see any difference on the products they
actually install, beside that two PTFS, in their
respective JCL ACCEPT streams.

Where I see BIG differences is in the "APPLY ALL" set
of PTFS which are installed. It looks the Volker allptfs.het tape
is quite different from the Moseley ptfs.het tape.

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I'm probably boring the list, but I like to post,
as a future reference, my analysis on the differences
between Volker/TK3 and Moseley SMP/DLIB, in their respective
SYSGEN.
I just tested the Volker tapes using the Moseley JCL
streams, to create DLIB SMP volumes, in the Volker style
(MVSBLB,SMP001,SMP002,SMP003,SMP004), with Volker datasets
allocation.
The only difference I can see in the way the DLIB are built
in Volker sg0070 and Moseley smpjob03.jcl, beside the
tape labels and format, are these two PTFS (UZ68825 UZ71903)
EDS1102 UZ68825 UZ71903 /* DM Support */
which Volker installs and Moseley doesn't.
Please correct me if my eyes are missing important
details on this quite important, I think, point.
The JCL I've written, modeled on the Moseley way, does
the job for the Volker tapes (and PTFS) without any
evident problem and with just some minor modification
(basically tape names and format, plus that EDS1102 couple of PTFS).
I had been able to SYSGEN a new 3350 MVS RESVOL using these
DLIBs (Volker-tapes-PTF built), again in the Moseley style.
That RESVOL, for what I may test right now (no VTAM/TSO),
IPL and start JES2 without any evident difference.
I'll try to SYSGEN a 3380/3390 new RESVOL, from that system
to test this weird system, an hybrid Volker-Moseley ;-) ... which,
I guess, has never been installed until now?
Peppe.

Well, it works, on a 3380 RESVOL.

And it also works the "giant" APPLY/ACCEPT Volker (sg0360/0370/0380/0390)
has in his TK3 setup, which apply and accept all
the PTFS received from on his "allptfs.het" tape, beside
a single PTF, UZ79497, with the SMP warning (RC=0004):

HMA4441 ASSEMBLY HRTPB360 FOR SRC HRTPB360 IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
HMA4441 ASSEMBLY HRTPLOAD FOR SRC HRTPLOAD IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
HMA4441 ASSEMBLY HRTPSYS3 FOR SRC HRTPSYS3 IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
HMA4441 ASSEMBLY HRTP1130 FOR SRC HRTP1130 IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED

But I can't see any track of that PTF in TK4- SYS1.SMPPTS either,so, I
guess, even in the Volker SYSGEN, it doesn't get installed.

The PTF UZ79497 seems to belong to the installed product

FMID (EML1102) - MULTI-LEAVING WORK STATION

----------++ PTF (UZ79497) /* 5752-SC1BL-EML1102-SCP
----------//UZ79497 JOB 5752-79497-0,SC1BL,MSGLEVEL=(1,1),CLASS=A */ .
----------++ VER (Z038) FMID (EML1102)
---------- SUP (AZ84440,UZ29226,UZ31359,UZ60892,UZ69654,UZ75069,
---------- UZ78127,AZ43643,AZ45771,AZ65879,AZ75904,AZ78416,
---------- AZ83006).
...
/*
---------- PROBLEM DESCRIPTION(S):
---------- OZ84440 USERS AFFECTED: REMOTE WORKSTATION USERS.
---------- AFTER APAR OZ78416 HRTPB360 GETS AN ASSEMBLY ERROR
---------- "UNDEFINED SYMBOL" FOR PCTOPCOD. ERROR OCCURS IF &MACHINE
---------- EQ 20 OR IS ALLOWED TO DEFAULT TO 20.
---------- TYPE/RESTART (HOT) IPL/REQUIRED (NO) CLPA (NO).
---------- HRTPB360 HAS BEEN UPDATED NEAR LABEL PSKIO, TO CHECK IF
---------- THE MACHINE IS MOD 20, SKIPPING THE EXPANSION OF PCTOPCOD
---------- IF SO.
---------- COMPONENT: 5752-SC1BL-EML1102

which I don't even have a fancy idea of which functions perform
in MVS3.8j.

The other problem I found, at least in sg0380/APPLY, is about
the working space the APPLY needs. It doesn't seem
a 3350 is large enough. I had been able to correctly perform
the apply only using a 3390:

//APPLY EXEC SMPAPP,WORK='3390'
//SYSUT1 DD UNIT=3390,SPACE=(CYL,(200,10,9000))
//SYSUT2 DD UNIT=3390,SPACE=(CYL,(200,10,9000))
//SYSUT3 DD UNIT=3390,SPACE=(CYL,(200,10,9000))
//SYSUT4 DD UNIT=3390,SPACE=(CYL,(200,10,9000))
//SMPWRK3 DD UNIT=3390,SPACE=(CYL,(200,10,9000)),DCB=(BLKSIZE=3120,
// LRECL=80)

otherwise I just get an SB37-04 abend from the job on
one of these datasets (space numbers are overallocated
to be sure they fit, but a 3350 doesn't fit). How the
hell Volker did using a 3350?

Anyway, now I've the "starting" point of basically
a TK3, generated from a plain Moseley, over a 3380
RESVOL, using mostly the JCL Jay Moseley provided
in his setup.

I've still to try, but I bet, now that all the
Volker PTFS are in place, I should be able to
install all the USERMODS Juergen applied over
the TK3 base system to get his TK4-, beside
any user manually applied customization.

All the PREREQ should be in place, beside such
single UZ79497 PTF and, eventually, its ifreqs/prereqs.

The system is just a plain IBM setup, with VTAM/TSO
configured now, which seems in a pretty good shape,
from what I've seen after the first IPL.

I can submit jobs, apply PTFS, logon to TSO with
the IBMUSER account.

Peppe.

[Tony Harminc [e-mail] [hercules-os380]]

On 21 November 2017 at 11:25, Giuseppe Vitillaro ***@vitillaro.org wrote:
[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
HMA4441 ASSEMBLY HRTPB360 FOR SRC HRTPB360 IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
HMA4441 ASSEMBLY HRTPLOAD FOR SRC HRTPLOAD IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
HMA4441 ASSEMBLY HRTPSYS3 FOR SRC HRTPSYS3 IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
HMA4441 ASSEMBLY HRTP1130 FOR SRC HRTP1130 IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
But I can't see any track of that PTF in TK4- SYS1.SMPPTS either,so, I
guess, even in the Volker SYSGEN, it doesn't get installed.
The PTF UZ79497 seems to belong to the installed product
FMID (EML1102) - MULTI-LEAVING WORK STATION

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
which I don't even have a fancy idea of which functions perform in MVS3.8j.

This is a unique situation in that the generated code does not run on
MVS at all, but on a "remote workstation", which in this case is
either a S/360 Model 20 or any other S/360 or S/370, or a similar
program for an IBM System/3, or again the same for the IBM 1130. The
result of this generation and/or PTF application is a standalone
program for the respective machines that is IPL'd on that remote
machine, and communicates via a BiSync line with JES2 on MVS.

So in real life, this "failure" matters not at all.

Tony H.

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

Post by Tony Harminc ***@gmail.com [hercules-os380]
[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
HMA4441 ASSEMBLY HRTPB360 FOR SRC HRTPB360 IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
HMA4441 ASSEMBLY HRTPLOAD FOR SRC HRTPLOAD IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
HMA4441 ASSEMBLY HRTPSYS3 FOR SRC HRTPSYS3 IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
HMA4441 ASSEMBLY HRTP1130 FOR SRC HRTP1130 IN SYSMOD UZ79497 WILL NOT BE DONE - DISTLIB NOT DETERMINED
But I can't see any track of that PTF in TK4- SYS1.SMPPTS either,so, I
guess, even in the Volker SYSGEN, it doesn't get installed.
The PTF UZ79497 seems to belong to the installed product
FMID (EML1102) - MULTI-LEAVING WORK STATION

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
which I don't even have a fancy idea of which functions perform in MVS3.8j.

This is a unique situation in that the generated code does not run on
MVS at all, but on a "remote workstation", which in this case is
either a S/360 Model 20 or any other S/360 or S/370, or a similar
program for an IBM System/3, or again the same for the IBM 1130. The
result of this generation and/or PTF application is a standalone
program for the respective machines that is IPL'd on that remote
machine, and communicates via a BiSync line with JES2 on MVS.
So in real life, this "failure" matters not at all.
Tony H.

Thanks Tony, appreciated.

If I understand correctly your post, the product
"MULTI-LEAVING WORK STATION", EML1102, is installed
but it is not present in my, and Moseley, SYSGEN.

I guess it hasn't been generated even from Volker,
(but is is installed anyway even in TK3)
in his original TK3 setup. It looks even TK4- miss
its configuration.

Probably would be a good idea to delete its installation
from the SMP generation. It doesn't seem a product
which I will use in any way in the future and it doesn't
seeem either anyone in our community used it in recent
years.

That would make possible to get a clean, clear execution
of "APPLY/ACCEPT ALL" from SMP.

Peppe.

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

By the way, I'm getting this error from JES2:

IKJ141I BROADCAST DATA SET NOT USABLE, INSTALLATION MUST REFORMAT

for the SYS1.BRODCAST dataset I placed on the 3380 RESVOL at SYSGEN time,
when I try to submit any JOB with the "NOTIFY=USERID" statement, while
"USERID" is not LOGON to TSO.

I guess JES2 doesn't like too much to have SYS1.BRODCAST
on a 3380 as any other of the dataset it uses?

May the SYS1.BRODCAST dataset be placed on a volume which
is not the RESVOL at SYSGEN time?

Peppe.

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

IKJ141I BROADCAST DATA SET NOT USABLE, INSTALLATION MUST REFORMAT
for the SYS1.BRODCAST dataset I placed on the 3380 RESVOL at SYSGEN time,

I looked up the message here:

http://www-03.ibm.com/systems/z/os/zos/library/bkserv/lookat/

which is one of the links in this group, and
it gave this:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2M9C1/SPTM012704

Use the SYNC subcommand of ACCOUNT to initialize the broadcast data set and synchronize it with the UADS. The SYNC subcommand can be issued in the foreground or in the background using the TMP in the background.


I would suggest trying that first, instead
of changing disks to try to avoid it.
Maybe an uninitialized dataset only
randomly works, or you haven't noticed
it before. So try their suggestion, which
I guess is:

//S1 EXEC PGM=IKJEFT01
//SYSTSIN DD *
account
sync
end
/*

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
IKJ141I BROADCAST DATA SET NOT USABLE, INSTALLATION MUST REFORMAT
for the SYS1.BRODCAST dataset I placed on the 3380 RESVOL at SYSGEN time,
when I try to submit any JOB with the "NOTIFY=USERID" statement, while
"USERID" is not LOGON to TSO.

If SYNC doesn't help, Sam Golob has a version of the code on cbttape.org

I've only run it on a 3350, but would expect him to supports modern DASD.


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Doesn't UADS use a non-standard I/O method? One (to 10) fixed sized
block per user id + sequence digit?

On Wed, Nov 22, 2017 at 7:12 AM, Gerhard Postpischil

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
IKJ141I BROADCAST DATA SET NOT USABLE, INSTALLATION MUST REFORMAT
for the SYS1.BRODCAST dataset I placed on the 3380 RESVOL at SYSGEN time,
when I try to submit any JOB with the "NOTIFY=USERID" statement, while
"USERID" is not LOGON to TSO.

If SYNC doesn't help, Sam Golob has a version of the code on cbttape.org
I've only run it on a 3350, but would expect him to supports modern DASD.
Gerhard Postpischil
Bradford, VT
---
This email has been checked for viruses by AVG.
http://www.avg.com
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Mike Schwab ***@gmail.com [hercules-os380]
Doesn't UADS use a non-standard I/O method? One (to 10) fixed sized
block per user id + sequence digit?

??? True, but irrelevant to SYS1.BRODCAST processing, other than having
a 1:1 match on user ids.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
IKJ141I BROADCAST DATA SET NOT USABLE, INSTALLATION MUST REFORMAT
for the SYS1.BRODCAST dataset I placed on the 3380 RESVOL at SYSGEN time,
when I try to submit any JOB with the "NOTIFY=USERID" statement, while
"USERID" is not LOGON to TSO.

If SYNC doesn't help, Sam Golob has a version of the code on cbttape.org
I've only run it on a 3350, but would expect him to supports modern DASD.
Gerhard Postpischil
Bradford, VT
---

I can't see any "SYNC" in the original Moseley
SYSGEN and it works on a 3350 of course.

Guess isn't here the problem, any way there
is not any SYNC command at my TSO prompt.

Guess is a subccomand of "ACCOUNT" command?

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
IKJ141I BROADCAST DATA SET NOT USABLE, INSTALLATION MUST REFORMAT
for the SYS1.BRODCAST dataset I placed on the 3380 RESVOL at SYSGEN time,
when I try to submit any JOB with the "NOTIFY=USERID" statement, while
"USERID" is not LOGON to TSO.

If SYNC doesn't help, Sam Golob has a version of the code on cbttape.org
I've only run it on a 3350, but would expect him to supports modern DASD.
Gerhard Postpischil
Bradford, VT
---

I can't see any "SYNC" in the original Moseley
SYSGEN and it works on a 3350 of course.
Guess isn't here the problem, any way there
is not any SYNC command at my TSO prompt.
Guess is a subccomand of "ACCOUNT" command?
Peppe.

Yes, it is:

help sync

FUNCTION -
THE SYNC SUBCOMMAND PROCESSOR PERFORMS THE ADMINISTRATIVE FUNCTION
OF FORMATING SYS1.BRODACST AND SYNCHRONIZING THE USERIDS IN THAT
DATA SET WITH THE USERIDS IN SYS1.UADS.

SYNTAX -
SYNC
REQUIRED - NONE
DEFAULTS - NONE

OPERANDS -
NONE

Peppe.

[Joe Monk [e-mail] [hercules-os380]]

here's what i had to do:

logon as ibmuser
then

alloc fi(sysuads) da('sys1.uads') shr

then
account

then
sync

then
end

Joe

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

IKJ141I BROADCAST DATA SET NOT USABLE, INSTALLATION MUST REFORMAT
for the SYS1.BRODCAST dataset I placed on the 3380 RESVOL at SYSGEN

time,

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

when I try to submit any JOB with the "NOTIFY=USERID" statement, while
"USERID" is not LOGON to TSO.

If SYNC doesn't help, Sam Golob has a version of the code on

cbttape.org

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
I've only run it on a 3350, but would expect him to supports modern

DASD.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
Gerhard Postpischil
Bradford, VT
---

I can't see any "SYNC" in the original Moseley
SYSGEN and it works on a 3350 of course.
Guess isn't here the problem, any way there
is not any SYNC command at my TSO prompt.
Guess is a subccomand of "ACCOUNT" command?
Peppe.

help sync
FUNCTION -
THE SYNC SUBCOMMAND PROCESSOR PERFORMS THE ADMINISTRATIVE FUNCTION
OF FORMATING SYS1.BRODACST AND SYNCHRONIZING THE USERIDS IN THAT
DATA SET WITH THE USERIDS IN SYS1.UADS.
SYNTAX -
SYNC
REQUIRED - NONE
DEFAULTS - NONE
OPERANDS -
NONE
Peppe.

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

Post by Joe Monk ***@gmail.com [hercules-os380]
logon as ibmuser
then
alloc fi(sysuads) da('sys1.uads') shr
then
account
then
sync
then
end
Joe

Yep, already done, Joe, it works.

Now I've to understand why in the "complete"
Moseley sequence of jobs, this particular
event doesn't happen.

I bet the problem is in "mvs02.jcl" which
add new users to the system?

By now I'm still with the original IBMUSER
account ONLY.

Any way, problem solved, it was not because
SYS1.BRODCAST is placed over a 3380, but just
that wasn't formatted, as the message suggested.

Thanks to all, Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
logon as ibmuser
then
alloc fi(sysuads) da('sys1.uads') shr
then
account
then
sync
then
end
Joe

Yep, already done, Joe, it works.
Now I've to understand why in the "complete"
Moseley sequence of jobs, this particular
event doesn't happen.
I bet the problem is in "mvs02.jcl" which
add new users to the system?
By now I'm still with the original IBMUSER
account ONLY.
Any way, problem solved, it was not because
SYS1.BRODCAST is placed over a 3380, but just
that wasn't formatted, as the message suggested.
Thanks to all, Peppe.

Yep, there were the lions ;-)

This simple JCL stream initialize the BROADCAST
dataset, problem solved ;-)

===========================================================================
//SYNC JOB (SYNC),'SYNC',
// CLASS=A,MSGLEVEL=(1,1),MSGCLASS=A
//*
//*********************************************************************
//*********************************************************************
//*
//LIST EXEC PGM=IKJEFT01
//SYSLBC DD DISP=SHR,DSN=SYS1.BRODCAST
//SYSUADS DD DSN=SYS1.UADS,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
ACCOUNT
SYNC
//
===========================================================================
Output:
----------------
ACCOUNT
SYNC
IKJ56589I BROADCAST DATA SET INITIALIZED AND SYNCHRONIZED
END
===========================================================================

The problem arose because Moseley has a really "involved" way
to add user to the system, using the utility PARMSWTR (which
source is not even available, just the module in Moseley SYSCPK
volume) and I missed this JCL code lines:

//PW13 EXEC PGM=PARMSWTR,
// PARM='@ LIST (&ID.)@ SYNC@ END'

so I was unaware SYS1.BRODCAST wasn't initialized on my system
(where mvs02.jcl has never run).

Looking to Volker and Moseley JCL, it seems "SYNC" has actually
to be used any time a new user is added to the system, in SYS1.UADS.

Because IBMUSER is already in SYS1.UADS (at SYSGEN time) and
SYS1.BRODCAST is a plain new dataset created at STAGE2 time,
logic allow to conclude that is quite what it should be expected
from a NEW system where users are still to be added.

Apologies for such a dummy question, Peppe.

[Tony Harminc [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
IKJ141I BROADCAST DATA SET NOT USABLE, INSTALLATION MUST REFORMAT
for the SYS1.BRODCAST dataset I placed on the 3380 RESVOL at SYSGEN time,
when I try to submit any JOB with the "NOTIFY=USERID" statement, while
"USERID" is not LOGON to TSO.
I guess JES2 doesn't like too much to have SYS1.BRODCAST
on a 3380 as any other of the dataset it uses?

I see the problem has been resolved, but just a comment:

It's not really acurate to say "getting this error from JES2". The
only reason you see it as coming from JES2 is because JES2 is issuing
an MVS console "SEND" command to send the "JOB ENDED" message to the
user. It is the SEND command that is failing, and you have figured out
why. Console "SEND" is conceptually much the same as TSO command
"SEND" (and is part of TSO), but the syntax and environment (and code)
are different. But is certainly has nothing to do with JES2 support
(or not) for any particular kind of disk geometry, and so is not
related to e.g. JES2 support for 3380 (or whatever) for SPOOL space.

Tony H.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If I understand correctly your post, the product
"MULTI-LEAVING WORK STATION", EML1102, is installed
but it is not present in my, and Moseley, SYSGEN.

FWIW, the enclosed program ($INDFILE text) supports a remote 370 as a
work station, but has been resequenced. I don't know whether it could be
of use to tk4- users. It came from some CBT file, but isn't on the tk
CBT disks. I also have a 360 version if anyone wants that (CBT file 860)


Gerhard Postpischil
Bradford, VT


---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Isn't the CTRLPROG RDE parameter which drive that?

That is an option, but I'm not sure about what I would loose

Assuming nothing of significance or relevance
to a Hercules system is lost ...

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Hi Peppe,The easiest way to prevent the unwanted message from appearing is to
rename module IFCRDE03 in SYS1.LINKLIB to some other name.
allow to turn on/off this feature, at runtime, without any
needs for a ZAP or a SYSGEN.
Better isn't?

I think configuring the sysgen "properly" is
cleaner than mucking around with load
modules.

But if you document in the job that does
the rename why you are doing it, and what
alternatives exist, that would also be fine.

Just my 2c. :-)

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Isn't the CTRLPROG RDE parameter which drive that?

That is an option, but I'm not sure about what I would loose

Assuming nothing of significance or relevance
to a Hercules system is lost ...

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Hi Peppe,The easiest way to prevent the unwanted message from appearing is to
rename module IFCRDE03 in SYS1.LINKLIB to some other name.
allow to turn on/off this feature, at runtime, without any
needs for a ZAP or a SYSGEN.
Better isn't?

I think configuring the sysgen "properly" is
cleaner than mucking around with load
modules.

But if you document in the job that does
the rename why you are doing it, and what
alternatives exist, that would also be fine.

Just my 2c. :-)

BFN. Paul.

---

Just done, Paul ;-)

Are you reading my mind?

Peppe.

[Joe Monk [e-mail] [hercules-os380]]

"and the SMP volumes which shouldn't care at all the DASD type."

Remember that the SMP we use to build with starts on 3.7, which only
accepts 3350's.

Joe

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way, I know I may read the IBM SMP manual, but it is
a bit difficult and I'm a bit lazy these days, after a
rather bad flue.

I hope your chimney gets unclogged soon <G>

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Anyone may help me understanding the JCL needed to list
ACCEPTED and APPLIED PTFS under MVS3.8j?

There is a LISTCDS program on the optional source: CBTCOV.FILE022. I
also have a modified version that doesn't require all the original's
contortion, but I'm not sure where I got it. The ASMTRACE proc is
basically an ASMFCLG with debug support.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
*00 IFB010D ENTER 'IPL REASON,SUBSYSTEM ID' OR 'U'

There is a "fix" for this, but it's a ZAP only (probably used it before
//MVSIFB10 JOB (0904,0012),GERHARD,CLASS=E
// EXEC SYSZAP,PDS=LPALIB
*
* THIS ZAP BYPASSES THE USELESS IFB010D WTOR (SPECIFY U OR
* IPL REASON - USELESS BECAUSE IT DOES NOT LET YOU
* SPECIFY THE REASON FOR THE IPL)
*
NAME IFBSVC76
VER 0648 0A23 WTOR
VER 064E 4100,0001,0A01 WAIT
*
REP 0648 0700
REP 064E 92E4,9000,0700 REPLY='U'
*

Thanks for the LISTCDS ref Gerhard, appreciated.
About the "REPLY U", I already know I may ZAP in this way, but I prefer to
rename a module (I don't remember now the name or the placement) which
take care of this request once and forever, it should be in the history of
our email lists.
Anyway, this is just a "test system", one of my steps in the direction of
my "New-Moseley".
I want to place as much as I can on 3390 DASDS, next step are RESVOL and
the SMP volumes which shouldn't care at all the DASD type. A couple of
them shouldn't be enough, isn't? One for the DLIBs and the other for the
current system.
Another test I'm going to perform is generating following the Moseley
procedures (almost, I already diverged), but using the Volker TK3 tapes,
as I would like to be near TK4- as much as I can, for when, and I'm
sure I will, I'll be in a bad corner and I'll ask for help.
So, at this very moment, I don't care at all about the "REPLY U"
noise.
By the way, a side question.
Moseley's procedures follow the idea to install as less
as possible from the PTF tape, while Volker's procedures
install as much as possobile.
Ehm ... what the hell, who is right here? ;-)
Thanks, Peppe.

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

Post by Joe Monk ***@gmail.com [hercules-os380]
"and the SMP volumes which shouldn't care at all the DASD type."
Remember that the SMP we use to build with starts on 3.7, which only
accepts 3350's.

Nope, I've a JCL set which builds new SMP volumes,
in the Volker's TK3 style (MVSDLB,SMP01-04), under
MVS3.8j-with-Morrison.

My 3380-SYSGEN use these new volumes, so, I'm hands
free to setup SMP volumes whatever I like.

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Moseley's procedures follow the idea to install as less
as possible from the PTF tape, while Volker's procedures
install as much as possobile.
Ehm ... what the hell, who is right here? ;-)

I was thinking about this. My understanding
is that some PTFs were for bug fixes, while
others were new development in object
code only form. And that you may be able
to distinguish the difference from the name
of the PTF.

I'm thinking that we should stick with just
the bug fixes, to stay closer to the source
code we have, unless someone can
identify a must-have enhancement and
maybe if they are willing to bring the
source code up-to-date including that
enhancement.

Also if you do that, you will have produced
a version between the two extremes -
minimal PTFs and maximum PTFs, which
may be useful in its own right, even just
as a reference.

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Moseley's procedures follow the idea to install as less
as possible from the PTF tape, while Volker's procedures
install as much as possobile.
Ehm ... what the hell, who is right here? ;-)

I was thinking about this. My understanding
is that some PTFs were for bug fixes, while
others were new development in object
code only form. And that you may be able
to distinguish the difference from the name
of the PTF.

I'm thinking that we should stick with just
the bug fixes, to stay closer to the source
code we have, unless someone can
identify a must-have enhancement and
maybe if they are willing to bring the
source code up-to-date including that
enhancement.

Also if you do that, you will have produced
a version between the two extremes -
minimal PTFs and maximum PTFs, which
may be useful in its own right, even just
as a reference.

BFN. Paul.

---

Well, it is a trickly problem.

Volker seems to have thought that his "allptfs.het"
tape was a sort of "definitive PTF tape", which
"close" all the IBM possible bugs and applied/accepted
all the PTF on that tape. Any other corrective
service wouldn't come from IBM, but from the community
as a USERMOD, not a SYSMOD.

From the history of TK3/TK4-, it seems he was right,
in the limits of what have been tested.

And there is another point. With his choice, Volker
was constrained to allocate SMP dataset in a way
which allow to install all the PTFs available, without
any possibile allocation error.

That is not the case of the Moseley choice. I know
for sure SMP Moseley allocation is too small: I get
ABEND E37-04 on a couple of SMP dataset with his choice.

By the way. Just run Moseley VTAM JCL "sysgen04.jcl" to
my 3380-SYSGEN. It works almost as is (beside volume
names).

I've a TSO "ibmuser" x3270 session open now, with my new
3380-SYSGEN ;-)

listc all
VOLUME -------- PEP380
HISTORY
RELEASE----------------2
CHARACTERISTICS
BYTES/TRK----------47968 DEVTYPE------X'3010200E'
MAX-PHYREC-SZ-
-----32760 DATASETS-ON-VOL--------3
TRKS/CYL--------------15 VOLUME-TIMESTAMP:
MAX-EXT/ALLOC-
---------5 DATASPCS-ON-VOL--------2

A side note.

With the new printer/punch JES2 configuration,
I didn't notice anymore any "delay" between
the "$P JES2" console command and the
"$HASP085 JES2 TERMINATION COMPLETE" console message:

/(0009) $P jes2
IEF404I INIT - ENDED - TIME=12.31.56
IEF404I INIT - ENDED - TIME=12.31.56
$HASP395 INIT ENDED
$HASP395 INIT ENDED
IEF404I INIT - ENDED - TIME=12.31.56
$HASP395 INIT ENDED
IEE043I A SYSTEM LOG DATA SET HAS BEEN QUEUED TO SYSOUT CLASS A
IEE037I LOG NOT ACTIVE
$HASP085 JES2 TERMINATION COMPLETE
IEF404I JES2 - ENDED - TIME=12.32.01

It is almost immediate, in the range of few seconds.

Just a accident?

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Volker seems to have thought that his "allptfs.het"
tape was a sort of "definitive PTF tape", which
"close" all the IBM possible bugs and applied/accepted
all the PTF on that tape. Any other corrective
service wouldn't come from IBM, but from the community
as a USERMOD, not a SYSMOD.

I think you're missing my point - those PTFs
may be definitive, but they include a mix of
bug fixes plus new development.

I think you should consider attempting to
extract only the bug fixes from IBM, not
the new development from IBM.

Secondly with regard to things like
3390 support needing accepted usermods,
perhaps you could consider:

1. Use MVS 3.7 just to create MVS 3.8j,
purely with IBM code.

2. Apply and accept just IBM's bug fixes to
create a new MVS 3.8j.

3. Apply and accept just Jim's 3380/3390
changes or anything else in that class, to
create a new MVS 3.8j.

4. Now you can add tons of changes, but
don't accept them.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
With the new printer/punch JES2 configuration,
I didn't notice anymore any "delay" between
the "$P JES2" console command and the

Probably good to try to isolate that
enhancement. If you were building in
a controlled, automated, reproducible
manner, that job might have been easier. :-)

BFN. Paul.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Volker seems to have thought that his "allptfs.het"
tape was a sort of "definitive PTF tape", which
"close" all the IBM possible bugs and applied/accepted
all the PTF on that tape. Any other corrective
service wouldn't come from IBM, but from the community
as a USERMOD, not a SYSMOD.

I think you're missing my point - those PTFs
may be definitive, but they include a mix of
bug fixes plus new development.

I think you should consider attempting to
extract only the bug fixes from IBM, not
the new development from IBM.

Secondly with regard to things like
3390 support needing accepted usermods,
perhaps you could consider:

1. Use MVS 3.7 just to create MVS 3.8j,
purely with IBM code.

2. Apply and accept just IBM's bug fixes to
create a new MVS 3.8j.

3. Apply and accept just Jim's 3380/3390
changes or anything else in that class, to
create a new MVS 3.8j.

4. Now you can add tons of changes, but
don't accept them.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
With the new printer/punch JES2 configuration,
I didn't notice anymore any "delay" between
the "$P JES2" console command and the

Probably good to try to isolate that
enhancement. If you were building in
a controlled, automated, reproducible
manner, that job might have been easier. :-)

BFN. Paul.

---

Paul, if I got the picture, if PTFS are not
ACCEPTED, they do not update the DLIB of the
current system, i.e., in other words, they
are not going down to a new SYSGEN, done
from that system.

The SMP logic, for what I read on the IBM manual is:

RECEIVE, just copy from MODs from tape to dasd
APPLY, which modify the "current system", not the DLIBs

then a sysadm may test the MODs on the "current"
and

RESTORE the "current system" as it was before

or

ACCEPT the mods on the DLIB to definitely
incorporate them on future SYSGEN and finally

REJECT

to erase the copy from the dasd where they had
been received.

Things may become quite complex to debug
if important mods are APPLIED but not ACCEPTED,
in DLIBs, for what I understand, when time
for a new SYSGEN come. And for sure, for a
reason or another, be sure it will come ;-)

By the way. At this moment all of my "tests"
had been done submitting jobs from the hercules
reader, so I've a record of all changes I'm doing
on my linux file system. The "cooperation" between
JCL and linux tools is ... well ... quite efficient ;-)

It is a rather confused mess of JCL, but I've
"grep/find" under linux helping me to keep track
of my modifications.

And I've a set of text documents which helps me
to "remember" how to apply this mess of JCL streams.

It is not fully automated, as you can see, but
I can go from one of my working copies of MVS3.8j
to a new set of SMP/MVS datasets, starting from
Moseley tapes and empty dasds, in less than 1h.

I'm getting a lot of fun, dissecting the Moseley
and Volker code, I think I'm going to the roots
of how a new MVS "shop" born ;-)

Another funny thing, at least for me, is how
efficiently I may work from the hercules reader with MVS,
using Linux as a development platform, compared to
working from TSO.

UNIX, for sure, it is not "silver bullet", it doesn't
work efficiently in a "transactional environment"
where thousands of users works together on the same
hardware.

But for individual or small group of developers ...
well ... it is a "silver bullet".

It born to solve this peculiar problem, at Bell Labs,
at its time and it has been solved quite well.

It is an unlucky fact the UNIX paradigm as been
applied to different problems ;-(

Peppe.

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

Post by ***@yahoo.com [hercules-os380]
If anyone wants me to post the scripts on
a different website, other than 4shared,
please let me know.

Hi Scott. It would be good if you could
post a more minimal archive to the files
area here.

If people want the original archives, I
think archive.org has them here:

https://web.archive.org/web/20141227083630/http://www.jaymoseley.com:80/hercules/installmvs/instmvs2.htm

Thanks. Paul.

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

Post by ***@yahoo.com [hercules-os380]
If anyone wants me to post the scripts on a
different website, other than 4shared, please
let me know.

Hi Scott.

Thanks for the recent upload, it was interesting
to see how you did it:

C:\scratch\mm777\jaymoseley_build\hercules\mvs\conf>head -20 sysgen.rc
devlist
logopt timestamp
panrate 1000

#devinit 170 tape/zdlib1.het
hao tgt IEA101A
hao cmd script conf/enter.rc
hao tgt HASP426 SPECIFY OPTIONS
hao cmd script conf/reply0n.rc
hao tgt C=BA
hao cmd script conf/m148ab.rc
#hao tgt HASP250 XXXXXX
#hao cmd devinit 012 jcl/writeipl.jcl eof
hao tgt HASP250 WRITEIPL
hao cmd devinit 012 jcl/sysgen00.jcl eof
hao tgt HASP250 SYSGEN00
hao cmd devinit 012 jcl/m3380.jcl eof
hao tgt HASP250 M3380
hao cmd devinit 012 jcl/m3390.jcl eof
hao tgt HASP250 M3390


What do you think about an alternative to
the above of combining all the JCL into a
single stream, ie:

copy sysgen00.jcl+m3380.jcl+... combine.jcl

so that you can do a single devinit:

devinit combine.jcl

Of course I would expect only one initiator
to be active so that they are run one at a
time in order.

Possibly another design would be to have
a variation of runmvs.bat and run them one
at a time that way.

Not sure which way is the nicest. I think I
would prefer to have a single batch file
with a sequence of runmvs or similar so
that I have minimal interaction with
Hercules itself and I just have to get one
batch file right. runmvs would need to be
a custom version to work with raw MVS 3.7,
and indeed, there may be more than one
runmvs (or at least the auto script) required.
My current runmvs is designed to work with
both a raw TK3 and an MVS/380, so has
two triggers and the first one hit clears the
other trigger. Perhaps that could be extended
to have triggers for all the major systems,
including MVS 3.7. Although I still need
custom scripts for doing things like formatting
the JES2 spool, so not everything can be
done with a standard runmvs.

BFN. Paul.

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

Post by ***@yahoo.com.au [hercules-os380]
Thanks for the recent upload, it was interesting
C:\scratch\mm777\jaymoseley_build\hercules\mvs\conf>head -20 sysgen.rc
devlist
logopt timestamp
panrate 1000
#devinit 170 tape/zdlib1.het
hao tgt IEA101A
hao cmd script conf/enter.rc
hao tgt HASP426 SPECIFY OPTIONS
hao cmd script conf/reply0n.rc
hao tgt C=BA
hao cmd script conf/m148ab.rc
#hao tgt HASP250 XXXXXX
#hao cmd devinit 012 jcl/writeipl.jcl eof
hao tgt HASP250 WRITEIPL
hao cmd devinit 012 jcl/sysgen00.jcl eof
hao tgt HASP250 SYSGEN00
hao cmd devinit 012 jcl/m3380.jcl eof
hao tgt HASP250 M3380
hao cmd devinit 012 jcl/m3390.jcl eof
hao tgt HASP250 M3390
What do you think about an alternative to
the above of combining all the JCL into a
copy sysgen00.jcl+m3380.jcl+... combine.jcl
devinit combine.jcl
Of course I would expect only one initiator
to be active so that they are run one at a
time in order.
Possibly another design would be to have
a variation of runmvs.bat and run them one
at a time that way.
Not sure which way is the nicest. I think I
would prefer to have a single batch file
with a sequence of runmvs or similar so
that I have minimal interaction with
Hercules itself and I just have to get one
batch file right. runmvs would need to be
a custom version to work with raw MVS 3.7,
and indeed, there may be more than one
runmvs (or at least the auto script) required.
My current runmvs is designed to work with
both a raw TK3 and an MVS/380, so has
two triggers and the first one hit clears the
other trigger. Perhaps that could be extended
to have triggers for all the major systems,
including MVS 3.7. Although I still need
custom scripts for doing things like formatting
the JES2 spool, so not everything can be
done with a standard runmvs.
BFN. Paul.

Hi Paul,


I honestly really don't understand what objective you are trying to accomplish.


The JCL jobs, scripts, run control and configuration files correspond to Jay M's (old) documented build process. I think that combining jobs, etc. will deviate from Jay's documented procedures and will deviate from my original objective of automating Jay's documented procedures.


And remember, I ended up scripting Jay's old build process. He now has a "new and improved" documented process which appears would need completely new scripts to be built to automate the build of Jay's new system.


Just as you took a break awhile back involving all things Hercules, I currently don't have the motivation to start all over and automate Jay's new process! But, that could certainly change at any time in the future!


ScottC

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

Hi Paul,

I never saw a reply from you on this.

Scott

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

Post by ***@yahoo.com [hercules-os380]
I never saw a reply from you on this.

Hi Scott. You didn't include context, so I
assume you are talking about the below.

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

Post by ***@yahoo.com.au [hercules-os380]
hao tgt HASP250 WRITEIPL
hao cmd devinit 012 jcl/sysgen00.jcl eof
hao tgt HASP250 SYSGEN00
hao cmd devinit 012 jcl/m3380.jcl eof
What do you think about an alternative to
the above of combining all the JCL into a
Possibly another design would be to have
a variation of runmvs.bat and run them one
at a time that way.
Not sure which way is the nicest.

I honestly really don't understand what
objective you are trying to accomplish.

I have difficulty explaining that.

In both the way you did it with Hercules
scripts, and the way I think would possibly
be better, using runmvs in batch files, we
are doing programming.

I think runmvs would allow the programming
to be done in Windows batch files rather
than in Hercules itself. So it would be easier
to replace Hercules with some other emulator,
or perhaps even a real mainframe, or perhaps
a remote Hercules that you can access via
ftp or somesuch. It would all be hidden under
runmvs.

Post by ***@yahoo.com [hercules-os380]
The JCL jobs, scripts, run control and
configuration files correspond to Jay M's
(old) documented build process. I think
that combining jobs, etc. will deviate from
Jay's documented procedures and will
deviate from my original objective of
automating Jay's documented procedures.

I don't think Jay's procedure of "run job x
then run job y then run job z" needs to be
followed to the letter and can't be replaced
with "run jobs x, y and z".

Basically I think the objective should be to
replace Jay's procedure with a better
procedure if we have a better one.

Post by ***@yahoo.com [hercules-os380]
And remember, I ended up scripting Jay's
old build process. He now has a "new and
improved" documented process which
appears would need completely new scripts
to be built to automate the build of Jay's
new system.

Sure, and when writing new scripts, *maybe*
it would be better to *write* a new runmvs
which would then be used for automatically
running jobs on Hercules, assuming that is
technically possible.

Post by ***@yahoo.com [hercules-os380]
Just as you took a break awhile back
involving all things Hercules,

Not sure which period you are referring to.
A couple of times I have stopped so that I
can think things through before being
influenced by others.

But yes, there are some times when I am
completely unmotivated and uninterested
and directionless. It's not something under
my control, but I am very happy that at the
moment I have an interest in making a
(somewhat limited, deliberately) 64-bit
version of mvssupa etc.

Post by ***@yahoo.com [hercules-os380]
I currently don't have the motivation to start
all over and automate Jay's new process!

It was not meant to be for you, it was for
Peppe, while he is following (or refining)
the building of MVS, he could choose to
either copy the way you did scripts, or
write a new runmvs. I was just putting some
additional ideas out there. So far it seems
that Peppe doesn't want to go down *any*
of those paths, which is fine, that's his call.

Post by ***@yahoo.com [hercules-os380]
But, that could certainly change at any
time in the future!

Sure. Hope to see you back on MVS. :-)

Apologies for not responding to the
above when you were expecting a reply.
I didn't (and don't) think what I wrote above
would be very valuable. At this point in time
I cannot definitively justify why I think a new
runmvs (or multiple ones, one for MVS 3.7,
one for raw MVS 3.8) should be written, and it
may not even be the correct approach, even
if it is technically possible.

BFN. Paul.

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

Post by Joe Monk ***@gmail.com [hercules-os380]
Simply put, it will not be possible to build a 3380/3390 system using the
processes described in the Moseley docs.
It might be possible to build a 3380 system on a modified moseley system,
because the MVS3.8J sysgen docs say that it is supported.
The thing that we have to remember is that we are "starting" with a 3.7
system, which has no clue about anything later than a 3350. Putting on the
Morrison mods allows the 3.7 system to "know" about 3375/80/90, but not
build an IPL image for them (this is what Kevin was talking about in the
ACCEPT SMP processing). The SMP processes in the moseley sysgen process
bring the 3.7 system to a point where it can sysgen a 3.8 system (i.e. the
DLIBS now contain 3.8 code and PTFS).
Thus, when the sysgen process happens for the 3.8 system, it is taking
place on a modified 3.7 system in the current moseley docs. (Modified
because it has the Morrison mods applied).
So, what we need to do is build a moseley 3.8J system without any DASD mods
as a "base or starter" system, just the way it would've come from IBM (i.e.
only 3350 support).
Then, we can apply the DASD mods from Morrison/Leonard and because we now
are using a 3.8J system as the "starter", it has a more than 50/50 chance
of working to natively build a 3380 RESVOL since the DLIBS will now be at a
3.8 level. versus a 0% chance on the 3.7 system.
Joe

Yep. Exactly what I did.

It definitely works for a 3380.

I bet it will work for a 3390 too.

But, for other restrictions, can't be
a 3390-ONLY system.

I've still to understand what Kevin means
by "ASM", but for sure paging and JES2 spool
can't be on a new pack model.

And I'm still getting this weird error at IPL time:

IEA855I INVALID VATLST00 ENTRY.'

from this SYS1.PARMLIB(VATLST00) member:

PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)
ZAZP01,0,2,3350 ,Y PAGE DATASETS (PRIVATE)
PUB000,1,2,3380 ,N PUBLIC DATASETS (PRIVATE)
PUB001,1,2,3390 ,N PUBLIC DATASETS (PRIVATE)
SMP000,1,2,3350 ,N DISTRIBUTION LIBRARIES (PRIVATE)
SORTW1,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW2,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW3,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW4,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW5,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW6,1,1,2314 ,N SORT WORK (PUBLIC)
SPOOL1,0,2,3350 ,Y JES2 QUEUES (PRIVATE)
SYSCPK,1,2,3350 ,N COMPILER/TOOLS (PRIVATE)
ZAZW00,1,0,3350 ,N WORK PACK (STORAGE)
ZAZW01,1,0,3350 ,N WORK PACK (STORAGE)

I can't understand where is coming from.

From what I've done, just changing the first two
lines of my usual Moseley member:

PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)

I bet on that "3380" on "SYSTEM RESIDENCE" PEP380 volume,
my new 3380 RESVOL.

May you see other mistakes, Joe?

From the other side, I've still to understand how to apply
the new Kevin's M096220 user mod. It has to be applied to
"generated" system and I've a bit of confusion around on
my SMPAPP cataloged procedures. The usermod is applied
to "generating" system and I guess is not a good idea
to ACCEPT it on the DLIBS.

I think is just enough to switch
to the new catalog on the new 3380 RESVOL,
using the original Kevin's JCL.

This should apply the ZAP to the SYS1.NUCLEUS(IEAVNP12)
on the new PEP380 RESVOL, instead that to the IEAVNP12
on the system I'm using to generate the new RESVOL, isn't?

Peppe.

[Tony Harminc [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I've still to understand what Kevin means
by "ASM", but for sure paging and JES2 spool
can't be on a new pack model.

ASM in this context means Auxiliary Storage Manager, which is the MVS
component that manages the disk part of paging, i.e. the places where
page slots live. The module and message prefix is ILR, and you may
sometimes see an ILR message warning of e.g. an auxiliary storage
shortage.

RSM (Real Storage Manage - IAR) manages the real storage, where page
frames live. And all of this is in support of Virtual Storage Manager,
which manages virtual pages, which are the things that application
programs deal with using GETMAIN/FREEMAIN et al.

Some of the prefixes have been changed or added to in modern (z/OS) systems.

This "ASM" has nothing to do with the assembler.

BTW, JES2 does not use ASM for its SPOOL dataset I/O. It manages its
own SPOOL allocation and I/O. Because JES2 is and has historically
been source maintained, I am pretty certain that adding the necessary
device support to it will be much easier than adding it to ASM.

Tony H.

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

Post by Tony Harminc ***@gmail.com [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I've still to understand what Kevin means
by "ASM", but for sure paging and JES2 spool
can't be on a new pack model.

ASM in this context means Auxiliary Storage Manager, which is the MVS
component that manages the disk part of paging, i.e. the places where
page slots live. The module and message prefix is ILR, and you may
sometimes see an ILR message warning of e.g. an auxiliary storage
shortage.
RSM (Real Storage Manage - IAR) manages the real storage, where page
frames live. And all of this is in support of Virtual Storage Manager,
which manages virtual pages, which are the things that application
programs deal with using GETMAIN/FREEMAIN et al.
Some of the prefixes have been changed or added to in modern (z/OS) systems.
This "ASM" has nothing to do with the assembler.
BTW, JES2 does not use ASM for its SPOOL dataset I/O. It manages its
own SPOOL allocation and I/O. Because JES2 is and has historically
been source maintained, I am pretty certain that adding the necessary
device support to it will be much easier than adding it to ASM.
Tony H.

Understood, Tony. Thanks for the post.

So, basically, it is the reason why paging
space is constrained to an old pack model, isn't?

Peppe.

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

PUB001 is only 3390. Do you get the error without it, or changing to 3380?
Perhaps PUB050-059 for 3350, PUB080-089 for 3380, PUB090-099 for 3390?

On Tue, Oct 31, 2017 at 11:42 AM, Giuseppe Vitillaro

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
Simply put, it will not be possible to build a 3380/3390 system using the
processes described in the Moseley docs.
It might be possible to build a 3380 system on a modified moseley system,
because the MVS3.8J sysgen docs say that it is supported.
The thing that we have to remember is that we are "starting" with a 3.7
system, which has no clue about anything later than a 3350. Putting on the
Morrison mods allows the 3.7 system to "know" about 3375/80/90, but not
build an IPL image for them (this is what Kevin was talking about in the
ACCEPT SMP processing). The SMP processes in the moseley sysgen process
bring the 3.7 system to a point where it can sysgen a 3.8 system (i.e. the
DLIBS now contain 3.8 code and PTFS).
Thus, when the sysgen process happens for the 3.8 system, it is taking
place on a modified 3.7 system in the current moseley docs. (Modified
because it has the Morrison mods applied).
So, what we need to do is build a moseley 3.8J system without any DASD mods
as a "base or starter" system, just the way it would've come from IBM (i.e.
only 3350 support).
Then, we can apply the DASD mods from Morrison/Leonard and because we now
are using a 3.8J system as the "starter", it has a more than 50/50 chance
of working to natively build a 3380 RESVOL since the DLIBS will now be at a
3.8 level. versus a 0% chance on the 3.7 system.
Joe

Yep. Exactly what I did.
It definitely works for a 3380.
I bet it will work for a 3390 too.
But, for other restrictions, can't be
a 3390-ONLY system.
I've still to understand what Kevin means
by "ASM", but for sure paging and JES2 spool
can't be on a new pack model.
IEA855I INVALID VATLST00 ENTRY.'
PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)
ZAZP01,0,2,3350 ,Y PAGE DATASETS (PRIVATE)
PUB000,1,2,3380 ,N PUBLIC DATASETS (PRIVATE)
PUB001,1,2,3390 ,N PUBLIC DATASETS (PRIVATE)
SMP000,1,2,3350 ,N DISTRIBUTION LIBRARIES (PRIVATE)
SORTW1,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW2,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW3,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW4,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW5,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW6,1,1,2314 ,N SORT WORK (PUBLIC)
SPOOL1,0,2,3350 ,Y JES2 QUEUES (PRIVATE)
SYSCPK,1,2,3350 ,N COMPILER/TOOLS (PRIVATE)
ZAZW00,1,0,3350 ,N WORK PACK (STORAGE)
ZAZW01,1,0,3350 ,N WORK PACK (STORAGE)
I can't understand where is coming from.
From what I've done, just changing the first two
PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)
I bet on that "3380" on "SYSTEM RESIDENCE" PEP380 volume,
my new 3380 RESVOL.
May you see other mistakes, Joe?
From the other side, I've still to understand how to apply
the new Kevin's M096220 user mod. It has to be applied to
"generated" system and I've a bit of confusion around on
my SMPAPP cataloged procedures. The usermod is applied
to "generating" system and I guess is not a good idea
to ACCEPT it on the DLIBS.
I think is just enough to switch
to the new catalog on the new 3380 RESVOL,
using the original Kevin's JCL.
This should apply the ZAP to the SYS1.NUCLEUS(IEAVNP12)
on the new PEP380 RESVOL, instead that to the IEAVNP12
on the system I'm using to generate the new RESVOL, isn't?
Peppe.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

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

Post by Mike Schwab ***@gmail.com [hercules-os380]
PUB001 is only 3390. Do you get the error without it, or changing to 3380?
Perhaps PUB050-059 for 3350, PUB080-089 for 3380, PUB090-099 for 3390?

I don't get any error when RESVOL is on a 3350 with these lines:

PEPRES,0,2,3350 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)
PEPP01,0,2,3350 ,Y PAGE DATASETS (PRIVATE)
PUB000,1,2,3380 ,N PUBLIC DATASETS (PRIVATE)
PUB001,1,2,3390 ,N PUBLIC DATASETS (PRIVATE)
SMP000,1,2,3350 ,N DISTRIBUTION LIBRARIES (PRIVATE)
SORTW1,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW2,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW3,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW4,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW5,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW6,1,1,2314 ,N SORT WORK (PUBLIC)
SPOOL1,0,2,3350 ,Y JES2 QUEUES (PRIVATE)
SYSCPK,1,2,3350 ,N COMPILER/TOOLS (PRIVATE)
PEPW00,1,0,3350 ,N WORK PACK (STORAGE)
PEPW01,1,0,3350 ,N WORK PACK (STORAGE)

Now ... where is the mistake, if any?

Peppe.

Post by Mike Schwab ***@gmail.com [hercules-os380]
On Tue, Oct 31, 2017 at 11:42 AM, Giuseppe Vitillaro

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
Simply put, it will not be possible to build a 3380/3390 system using the
processes described in the Moseley docs.
It might be possible to build a 3380 system on a modified moseley system,
because the MVS3.8J sysgen docs say that it is supported.
The thing that we have to remember is that we are "starting" with a 3.7
system, which has no clue about anything later than a 3350. Putting on the
Morrison mods allows the 3.7 system to "know" about 3375/80/90, but not
build an IPL image for them (this is what Kevin was talking about in the
ACCEPT SMP processing). The SMP processes in the moseley sysgen process
bring the 3.7 system to a point where it can sysgen a 3.8 system (i.e. the
DLIBS now contain 3.8 code and PTFS).
Thus, when the sysgen process happens for the 3.8 system, it is taking
place on a modified 3.7 system in the current moseley docs. (Modified
because it has the Morrison mods applied).
So, what we need to do is build a moseley 3.8J system without any DASD mods
as a "base or starter" system, just the way it would've come from IBM (i.e.
only 3350 support).
Then, we can apply the DASD mods from Morrison/Leonard and because we now
are using a 3.8J system as the "starter", it has a more than 50/50 chance
of working to natively build a 3380 RESVOL since the DLIBS will now be at a
3.8 level. versus a 0% chance on the 3.7 system.
Joe

Yep. Exactly what I did.
It definitely works for a 3380.
I bet it will work for a 3390 too.
But, for other restrictions, can't be
a 3390-ONLY system.
I've still to understand what Kevin means
by "ASM", but for sure paging and JES2 spool
can't be on a new pack model.
IEA855I INVALID VATLST00 ENTRY.'
PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)
ZAZP01,0,2,3350 ,Y PAGE DATASETS (PRIVATE)
PUB000,1,2,3380 ,N PUBLIC DATASETS (PRIVATE)
PUB001,1,2,3390 ,N PUBLIC DATASETS (PRIVATE)
SMP000,1,2,3350 ,N DISTRIBUTION LIBRARIES (PRIVATE)
SORTW1,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW2,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW3,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW4,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW5,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW6,1,1,2314 ,N SORT WORK (PUBLIC)
SPOOL1,0,2,3350 ,Y JES2 QUEUES (PRIVATE)
SYSCPK,1,2,3350 ,N COMPILER/TOOLS (PRIVATE)
ZAZW00,1,0,3350 ,N WORK PACK (STORAGE)
ZAZW01,1,0,3350 ,N WORK PACK (STORAGE)
I can't understand where is coming from.
From what I've done, just changing the first two
PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)
I bet on that "3380" on "SYSTEM RESIDENCE" PEP380 volume,
my new 3380 RESVOL.
May you see other mistakes, Joe?
From the other side, I've still to understand how to apply
the new Kevin's M096220 user mod. It has to be applied to
"generated" system and I've a bit of confusion around on
my SMPAPP cataloged procedures. The usermod is applied
to "generating" system and I guess is not a good idea
to ACCEPT it on the DLIBS.
I think is just enough to switch
to the new catalog on the new 3380 RESVOL,
using the original Kevin's JCL.
This should apply the ZAP to the SYS1.NUCLEUS(IEAVNP12)
on the new PEP380 RESVOL, instead that to the IEAVNP12
on the system I'm using to generate the new RESVOL, isn't?
Peppe.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

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

PEPRES,0,2,3350 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)

I don't know the answer to your question,
but it is unusual to see a space like that
in MVS, ie between "3350" and ",Y".

BFN. Paul.

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

Not on the mainframe. The following comma MUST be in a specific column.

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

PEPRES,0,2,3350 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)

I don't know the answer to your question,
but it is unusual to see a space like that
in MVS, ie between "3350" and ",Y".
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

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

Hi Mike, Peppe, Paul


Exactly, and in the given case it has to be in column 20 (see for example on https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/vatsps.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/vatsps.htm). Sorry that I didn't see this thread earlier, I had of course cleared it up immediately.



Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Not on the mainframe. The following comma MUST be in a specific column.

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

PEPRES,0,2,3350 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)

I don't know the answer to your question,
but it is unusual to see a space like that
in MVS, ie between "3350" and ",Y".
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I don't know the answer to your question,
but it is unusual to see a space like that
in MVS, ie between "3350" and ",Y".

Most of the NIP functions are relatively primitive, and it was easier to
require a fixed column (allowing room for things like 3330-1).

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

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

PEPRES,0,2,3350 ,Y SYSTEM RESIDENCE (PRIVATE)

How about ensuring that there is just one
change, so that you can isolate the fault?

Currently I see this:

C:\scratch>diff -w peppe_good.txt peppe_bad.txt
1c1
< PEPRES,0,2,3350 ,Y SYSTEM RESIDENCE (PRIVATE)
---

PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)

3c3
< PEPP01,0,2,3350 ,Y PAGE DATASETS (PRIVATE)
---

ZAZP01,0,2,3350 ,Y PAGE DATASETS (PRIVATE)

15,16c15,16
< PEPW00,1,0,3350 ,N WORK PACK (STORAGE)
< PEPW01,1,0,3350 ,N WORK PACK (STORAGE)
---

ZAZW00,1,0,3350 ,N WORK PACK (STORAGE)
ZAZW01,1,0,3350 ,N WORK PACK (STORAGE)

Maybe it doesn't like packs starting with "Z"
or something.

I can't understand why 3380 and 3390 would
be accepted for some packs, but not others.

Another thing you could try is seeing if
you can change this ",N":

PUB001,1,2,3390 ,N PUBLIC DATASETS (PRIVATE)

to ",Y". Maybe it is only ",N" (whatever that is)
that are allowed on a 3380/3390.

Because I can't see why it would only complain
about the first line. How does it know that is
special? I assume that "SYSTEM RESIDENCE"
is just treated as a comment, nothing special.

BFN. Paul.

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

PEPRES,0,2,3350 ,Y SYSTEM RESIDENCE (PRIVATE)

How about ensuring that there is just one
change, so that you can isolate the fault?

Currently I see this:

C:\scratch>diff -w peppe_good.txt peppe_bad.txt
1c1
< PEPRES,0,2,3350 ,Y SYSTEM RESIDENCE (PRIVATE)
---

PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)

3c3
< PEPP01,0,2,3350 ,Y PAGE DATASETS (PRIVATE)
---

ZAZP01,0,2,3350 ,Y PAGE DATASETS (PRIVATE)

15,16c15,16
< PEPW00,1,0,3350 ,N WORK PACK (STORAGE)
< PEPW01,1,0,3350 ,N WORK PACK (STORAGE)
---

ZAZW00,1,0,3350 ,N WORK PACK (STORAGE)
ZAZW01,1,0,3350 ,N WORK PACK (STORAGE)

Maybe it doesn't like packs starting with "Z"
or something.

I can't understand why 3380 and 3390 would
be accepted for some packs, but not others.

Another thing you could try is seeing if
you can change this ",N":

PUB001,1,2,3390 ,N PUBLIC DATASETS (PRIVATE)

to ",Y". Maybe it is only ",N" (whatever that is)
that are allowed on a 3380/3390.

Because I can't see why it would only complain
about the first line. How does it know that is
special? I assume that "SYSTEM RESIDENCE"
is just treated as a comment, nothing special.

BFN. Paul.

---

This is actually a comment, Paul.

I suspect doesn't like a 3380 together with "0,2".

It is the first time I use this combination.

May be?

Peppe.

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I suspect doesn't like a 3380 together with "0,2".

Yes, that's a good theory to test.

Try starting with the working version and
then changing PUB000 from "1,2" to
"0,2" and see if that induces an error.

If that doesn't, then go back to "1,2"
and try changing ",N" to ",Y".

And when you've isolated the problem,
ask here or (probably better, so that
you get Tom and Kevin) H390-MVS
for a theory and hopefully a code fix. :-)

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
SORTW1,1,1,2314 ,N SORT WORK (PUBLIC)

Are you certain you want these public. Mine are mounted private, and the
SORT procedures refer to them with
//SORTWK01 DD UNIT=2314,SPACE=(CYL,&CYL),VOL=SER=SORT01
etc.

Also, mine are defined read only, with the created extensions in a
separate directory, that is scratched in the .BAT file I use to start
Hercules (ditto for SYSDA, CBTxxx, and SRCxxx).

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Joe Monk [e-mail] [hercules-os380]]

Peppe,

IEA855I is informational. The system still processes the rest of the list.

So what I would do is a D U,DASD,ONLINE and see what volumes are mounted.
That should tell you where the error is.

Joe

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
Simply put, it will not be possible to build a 3380/3390 system using the
processes described in the Moseley docs.
It might be possible to build a 3380 system on a modified moseley system,
because the MVS3.8J sysgen docs say that it is supported.
The thing that we have to remember is that we are "starting" with a 3.7
system, which has no clue about anything later than a 3350. Putting on

the

Post by Joe Monk ***@gmail.com [hercules-os380]
Morrison mods allows the 3.7 system to "know" about 3375/80/90, but not
build an IPL image for them (this is what Kevin was talking about in the
ACCEPT SMP processing). The SMP processes in the moseley sysgen process
bring the 3.7 system to a point where it can sysgen a 3.8 system (i.e.

the

Post by Joe Monk ***@gmail.com [hercules-os380]
DLIBS now contain 3.8 code and PTFS).
Thus, when the sysgen process happens for the 3.8 system, it is taking
place on a modified 3.7 system in the current moseley docs. (Modified
because it has the Morrison mods applied).
So, what we need to do is build a moseley 3.8J system without any DASD

mods

Post by Joe Monk ***@gmail.com [hercules-os380]
as a "base or starter" system, just the way it would've come from IBM

(i.e.

Post by Joe Monk ***@gmail.com [hercules-os380]
only 3350 support).
Then, we can apply the DASD mods from Morrison/Leonard and because we now
are using a 3.8J system as the "starter", it has a more than 50/50 chance
of working to natively build a 3380 RESVOL since the DLIBS will now be

at a

Post by Joe Monk ***@gmail.com [hercules-os380]
3.8 level. versus a 0% chance on the 3.7 system.
Joe

Yep. Exactly what I did.
It definitely works for a 3380.
I bet it will work for a 3390 too.
But, for other restrictions, can't be
a 3390-ONLY system.
I've still to understand what Kevin means
by "ASM", but for sure paging and JES2 spool
can't be on a new pack model.
IEA855I INVALID VATLST00 ENTRY.'
PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)
ZAZP01,0,2,3350 ,Y PAGE DATASETS (PRIVATE)
PUB000,1,2,3380 ,N PUBLIC DATASETS (PRIVATE)
PUB001,1,2,3390 ,N PUBLIC DATASETS (PRIVATE)
SMP000,1,2,3350 ,N DISTRIBUTION LIBRARIES (PRIVATE)
SORTW1,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW2,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW3,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW4,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW5,1,1,2314 ,N SORT WORK (PUBLIC)
SORTW6,1,1,2314 ,N SORT WORK (PUBLIC)
SPOOL1,0,2,3350 ,Y JES2 QUEUES (PRIVATE)
SYSCPK,1,2,3350 ,N COMPILER/TOOLS (PRIVATE)
ZAZW00,1,0,3350 ,N WORK PACK (STORAGE)
ZAZW01,1,0,3350 ,N WORK PACK (STORAGE)
I can't understand where is coming from.
From what I've done, just changing the first two
PEP380,0,2,3380 ,Y SYSTEM RESIDENCE (PRIVATE)
MVSDLB,0,2,3350 ,Y SYSTEM DATASETS (PRIVATE)
I bet on that "3380" on "SYSTEM RESIDENCE" PEP380 volume,
my new 3380 RESVOL.
May you see other mistakes, Joe?
From the other side, I've still to understand how to apply
the new Kevin's M096220 user mod. It has to be applied to
"generated" system and I've a bit of confusion around on
my SMPAPP cataloged procedures. The usermod is applied
to "generating" system and I guess is not a good idea
to ACCEPT it on the DLIBS.
I think is just enough to switch
to the new catalog on the new 3380 RESVOL,
using the original Kevin's JCL.
This should apply the ZAP to the SYS1.NUCLEUS(IEAVNP12)
on the new PEP380 RESVOL, instead that to the IEAVNP12
on the system I'm using to generate the new RESVOL, isn't?
Peppe.

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

Post by Joe Monk ***@gmail.com [hercules-os380]
Peppe,
IEA855I is informational. The system still processes the rest of the list.
So what I would do is a D U,DASD,ONLINE and see what volumes are mounted.
That should tell you where the error is.

I did, Joe.

I can't see any problem on my dasd online list.

That the reason I think it is the first line.

What I can try, it is just delete the first line
and see if the warning is still there.

I guess MVS would IPL in any case, beside
the presence of this line for the RESVOL.

Peppe.

[Joe Monk [e-mail] [hercules-os380]]

"But you know, as Greg Price just defined me ...
it seems I'm a "maverick".

I don't know if I'm, but for sure I just learned
a new english word ;-)"

A maverick is a male horse, running wild and free. So the comparison is
that we are trying to make an old dog (MVS 3.8J) do new tricks (3380
RESVOL), so we are, in essence mavericks...

A nice compliment!

Joe

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

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, I'm doing all of my work on Moseley
SYSGEN from a 3215-C console, I don't even
touch a 3270 console.

Ok, cool.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Minor changes are needed to Moseley STAGE1
to support a 3215-C console at IPL time, if
I remember correctly, something like that
(a diff from my Moseley "hell" ;-))
in sysgen01.jcl.

Ok. So what do you think about doing a
context diff of the changes you made,
and then applying that as a patch?

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I'm definitely not that good when time to document
my changes come ;-(

Well they don't really need to be documented
if they are simply included in an automatic
script to build the system you are trying to
build.
What do you think about creating some auto
scripts?
BFN. Paul.
---
For what I've seen so far, Paul, automating
the Moseley SYSGEN is going to be a nightmare.
I understand it may be useful, but, I guess,
Moseley SYSGEN, as the Volker TK3 SYSGEN, it
is not that easy to handle, even manually.
And most of the "pleasure" in performing such
a work is coming from modifying the J.Moseley
JCL streams, for understanding or to get new
features alive.
So far, I don't feel any need to automate
the process, but I'm still in the middle
of an ancient "abandoned" track.
I'm still trying to understand, and change,
the Moseley code.
Actually I'm trying to get ... how
to call it ... an "hybrid" ... between the Moseley
and the Volker SYSGEN.
Both the approaches, from my point of view,
have pro and cons.
I'm trying to get the best from both and,
at the same time, gaining some knowledge
on MVS and SMP.
But you know, as Greg Price just defined me ...
it seems I'm a "maverick".
I don't know if I'm, but for sure I just learned
a new english word ;-)
Peppe.

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

Post by Joe Monk ***@gmail.com [hercules-os380]
"But you know, as Greg Price just defined me ...
it seems I'm a "maverick".
I don't know if I'm, but for sure I just learned
a new english word ;-)"
A maverick is a male horse, running wild and free. So the comparison is
that we are trying to make an old dog (MVS 3.8J) do new tricks (3380
RESVOL), so we are, in essence mavericks...
A nice compliment!
Joe

Yep, Joe.

I'm not a native english speaker, but I recognized it ;-)

Peppe.