开云体育

I had various issues with SYSCPK install and contents.

First, the changes to the JES2 procedure:

• #1 with a bullet
• This (as suggested on ) won't work:
  ??? S JES2OLD
  JES2OLD is not a registered subsystem, and thus the START command will hang.
  
• The JES2 procedure is not modified in a consistent style with the preexisting statements:
• SYSC.PROCLIB was hardcoded, unlike SYS1.PROCLIB and SYS2.PROCLIB.?
  
• When combined with #1 above and a user mistake by me (!), my recovery entailed restoring from my nightly backups.?
  
• The preferred (and recoverable from) method of adding the PROCLIB would have been:
• Adding parameters PC= and VC= (for volume) to the new library
• I would also suggest also use of UNIT=SYSDA, not UNIT=3350.
  
• SYSC.PROCLIB was in front of SYS1.PROCLIB
• This is not acceptable (not on my system!), and a bad practice in general.? End of the (DD) line, please.
• You could add an alternate PROCLIB DD (/*JOBPARM PROCLIB=SYSC?)
• Are there duplicate names between SYS1.PROCLIB AND SYSC.PROCLIB?
  
• On a system with dynamic PROCLIB support, is adding SYSC.PROCLIB directly to JES2 needed at all?? (At cost of an additional line of JCL, of course.)
  

SYSC.LINKLIB has multiple minor issues:

• The library seems to be dumping ground for multiple module types; I would suggest it be audited and replaced with:
  
• A library for executable language components (under the current name?)
• Is there a summary of changes for modules which also in SYS1.LINKLIB?
  
• A library for executable utilities
  
• A library for linkable subroutines
  
• Adding SYSC.LINKLIB with its 905 members (SYS1.LINKLIB only has 121) to the APF authorized list is somewhat cavalier.?
  
• Is there a summary of what modules need authorization (and why)?
  
• I would think once reorganized, only the utilities library needs APF authorization?
  

And finally, the VATLST modifier didn't detect SYSCPK was already added to VATLST00, and inserted a duplicate entry.? As (I think) that was the only line modified, the entire step should have been skipped. (Do the other steps have duplicate changes issues as well?

-- 
Drew Derbyshire

Mobile: 425-471-8183

"The only thing necessary for the triumph of evil is for good men to do
 nothing."

On 6/25/20 3:36 AM, Joe Monk wrote:

While Jay Moseley does not need defending, the procedure was written to be compatible with his MVS build.

This is not accurate.? To quote "In order to be compatible with the largest number of Hercules/MVS users ...".? Clearly Jay is targeting a wide audience.

Because he is targeting a wide audience including older (out of date) systems, much of the content on the pack is redundant for a TK3UPD system.? This is to be expected and is harmless.? But I didn't even mention fact in that my original note. (That's not a bug, it's a feature!)

Also, I did not comment on what he got right (I would have been here all night), for example making SYSC.LINKLIB a STEPLIB rather than adding it to the system link list.

If you are using his procedure?with another system like TK3UPD (which last I heard has questionable legs anyway, because Phil decided to claim copyright over the whole thing),

In an earlier thread discussing my need to apply service, it was pointed out that TK3UPD was the basis for MVS380 and TK4-; those questionable legs have traveled, to say the least.

of there will be a need to modify the install procedures.

In what way?

What I reported were not customization issues, but rather a failure to follow best? practices.? (The order of PROCLIB entries can be argued ... but not the system failing to start!)

So, when viewed thru that lens, none of these changes are either unusual or unnecessary. Every system takes some customization.

My original tone, which I am sticking by, is that on any MVS system (including Jay's) the original approaches are not best practices and they should be corrected.

For example, if one generating new entries for VATLST, one should verify they are, in fact, new.? And "S JES2OLD" just won't work.

I lost a moderate amount of work because of having to restore, and I prefer no one else does.

-ahd-

--
Drew Derbyshire

"Ain't there one damn song that can me break down and cry?"
-- David Bowie

On Thu, Jun 25, 2020 at 01:33 PM, Drew Derbyshire wrote:

I lost a moderate amount of work because of having to restore, and I prefer no one else does.

If you had to restore because you had mucked up something in PARMLIB, you have the option to IPL ZZSA, fix whatever (JES2PARM, VATLST00, ...), then try to IPL MVS again.

On 6/24/20 9:34 PM, Drew Derbyshire wrote:

(Blew your address the first time.? Ooops.)
I had various issues with SYSCPK install and contents.
First, the changes to the JES2 procedure:
* #1 with a bullet
o This (as suggested on
)
won't work:
??? S JES2OLD
JES2OLD is not a registered subsystem, and thus the START
command will hang.
* The JES2 procedure is not modified in a consistent style with
the preexisting statements:
o SYSC.PROCLIB was hardcoded, unlike SYS1.PROCLIB and
SYS2.PROCLIB.
o When combined with #1 above and a user mistake by me (!), my
recovery entailed restoring from my nightly backups.
+ The preferred (and recoverable from) method of adding
the PROCLIB would have been:
+ Adding parameters PC= and VC= (for volume) to the new
library
+ I would also suggest also use of UNIT=SYSDA, not UNIT=3350.
* SYSC.PROCLIB was in front of SYS1.PROCLIB
o This is not acceptable (not on my system!), and a bad
practice in general.? End of the (DD) line, please.
o You could add an alternate PROCLIB DD (/*JOBPARM PROCLIB=SYSC?)
o Are there duplicate names between SYS1.PROCLIB AND SYSC.PROCLIB?
* On a system with dynamic PROCLIB support, is adding SYSC.PROCLIB
directly to JES2 needed at all?? (At cost of an additional line
of JCL, of course.)
SYSC.LINKLIB has multiple minor issues:
* The library seems to be dumping ground for multiple module types; I
would suggest it be audited and replaced with:
o A library for executable language components (under the current
name?)
+ Is there a summary of changes for modules which also in
SYS1.LINKLIB?
o A library for executable utilities
o A library for linkable subroutines
* Adding SYSC.LINKLIB with its 905 members (SYS1.LINKLIB only has 121)
to the APF authorized list is somewhat cavalier.
o Is there a summary of what modules need authorization (and why)?
o I would think once reorganized, only the utilities library needs
APF authorization?
And finally, the VATLST modifier didn't detect SYSCPK was already added to VATLST00, and inserted a duplicate entry.? As (I think) that was the only line modified, the entire step should have been skipped. (Do the other steps have duplicate changes issues as well?

Drew,

I am sure you have some valid points in your list above. The integration job and procedure have not been updated since 2015 and was originally targeted to people who were building a system based on my instructions. It seems most of the people from whom I have feedback about SYSCPK are adding it to z/OS or Turnkey systems and are doing the process manually.

SYSC.LINKLIB on the current SYSCPK contains 805 members according to REVINFO. The vast majority of those are language compilers; just scrolling through the list the largest number are related to PL/1, Simula, RPG, and IFOX00 assembler. Dividing the modules by function would not be a hardship on me, but would overly complicate what was intended only to be a simple way of collecting useful modules in a central location. It was never a design point to consider response time for what is a 'hobby use' system. If anyone is interested in making sub-millisecond response time they are probably more aware than I am as to what changes to make and, in my opinion, are 'tilting at windmills'. The response I receive on my system rivals anything I experienced on real mainframes. I remember one place that was so slow that you would make as many changes on your ISPF screen as you could, then press Enter and take a sip of coffee while it made the round trip to the mainframe and back.

It sounds like you prefer the Dynamic Proclib approach, so that is probably what you should use and integrate the load modules, procedures and library PDSes into your system using the method you prefer. I have tried Brian Westerman's Dynamic Proclib and didn't particularly care for it, although it is included on another page at my site and I heartily recommend it to anyone for whom that approach appeals to them and works for them. I have also backfitted a Usermod to allow SYSC.LINKLIB to be concatenated into the Link List, and it works great for me on my system. Would it work for everyone? Probably not, but the nature of running MVS (or DOS/VS, VM, or MVT) under Hercules is that it is *your* system. You can customize it any way that you prefer.

I will add your list onto the list of things I consider when updating various parts of my site. At the present time if I were updating the SYSCPK page I would probably simply remove the integration instructions/program and leave it to each individual to integrate it as they see fit.

Jay

开云体育

On Thu, Jun 25, 2020 at 01:33 PM, Drew Derbyshire wrote:

I lost a moderate amount of work because of having to restore, and I prefer no one else does.

If you had to restore because you had mucked up something in PARMLIB, you have the option to IPL ZZSA, fix whatever (JES2PARM, VATLST00, ...), then try to IPL MVS again.

You missed a step, namely I need "get a clue" first.? :-)

Thanks!

-ahd-

-- 
Drew Derbyshire

"Do not send unsolicited advertising, chain letters, automatic messages
 or other spam to this address. Abuse of our e-mail resources may
 result in legal action or a leather-winged demon of the night dining on
 your pancreas."    -- 

开云体育

SYSC.LINKLIB on the current SYSCPK contains 805 members according to REVINFO. The vast majority of those are language compilers; just scrolling through the list the largest number are related to PL/1, Simula, RPG, and IFOX00 assembler. Dividing the modules by function would not be a hardship on me, but would overly complicate what was intended only to be a simple way of collecting useful modules in a central location. It was never a design point to consider response time for what is a 'hobby use' system. If anyone is interested in making sub-millisecond response time they are probably more aware than I am as to what changes to make and, in my opinion, are 'tilting at windmills'.

My concern is not response time but security. Given good security on MVS (RAKF is in my sights) and a reliable 4361, I'd talk to the owners about putting up an MVS guest. So having such a huge library APF authorized is not my style.

(In general, I secure and backup my hobby systems like they were production. I have MFA on my home gateway machine, for example.)

The response I receive on my system rivals anything I experienced on real mainframes.

My test machine for the LCML 4361 is several times faster than the live hardware ... and the test hardware would fit in the 4361's 8" floppy slot. :-)

I remember one place that was so slow that you would make as many changes on your ISPF screen as you could, then press Enter and take a sip of coffee while it made the round trip to the mainframe and back.

I turned my Hercules system into THAT last week with the misconfigured printer adventure.?

Back at Clarkson University on CLVM, 3 PM weekdays was like that.? Couldn't fix it by turning off a printer, either.

It sounds like you prefer the Dynamic Proclib approach, so that is probably what you should use and integrate the load modules, procedures and library PDSes into your system using the method you prefer.

I had it for 4 years at in the 1980's, so it was rote, like coding a correct JOB card.? But Hercules uses a different name, which I can never remember.? :-)

I have also backfitted a Usermod to allow SYSC.LINKLIB to be concatenated into the Link List, and it works great for me on my system. Would it work for everyone? Probably not, but the nature of running MVS (or DOS/VS, VM, or MVT) under Hercules is that it is *your* system. You can customize it any way that you prefer.

That's reasonable.? What drives me batty are people who make system-wide changes to suit their preferences.? On Linux for example, I've seen colorized directory lists enabled in a system-wide profile) and changing the default of how IPv6 addresses are generated (rather then simply enabling the possibility.)?

(The directory colorized lists drove me crazy because they assumed a different color background.)

SYSC.PROCLIB first is a preference, one I don't agree with.?

Hardcoding the name in the procedure I would not call a preference, but I feel an error.

I will add your list onto the list of things I consider when updating various parts of my site. At the present time if I were updating the SYSCPK page I would probably simply remove the integration instructions/program and leave it to each individual to integrate it as they see fit.

The catalog connection step was very useful.? (I never really made friends with AMS.)

Do let us know to do (and how to do) the rest of the steps.? :-)

-- 
Drew Derbyshire

"As a fan, I'm distraught [that Calvin and Hobbes ended], but as a
 cartoonist looking at new vacant spaces in 2,400 newspapers, well,
 behind me, my cats are dancing a conga line."  -- Scott Adams

On Thu, Jun 25, 2020 at 02:08 PM, Jay Moseley wrote:

It sounds like you prefer the Dynamic Proclib approach, so that is probably what you should use and integrate the load modules, procedures and library PDSes into your system using the method you prefer. I have tried Brian Westerman's Dynamic Proclib and didn't particularly care for it, although it is included on another page at my site and I heartily recommend it to anyone for whom that approach appeals to them and works for them. I have also backfitted a Usermod to allow SYSC.LINKLIB to be concatenated into the Link List, and it works great for me on my system.

Jay, what didn't you like about the dynamic proclib? (I'm not trying to spark an argument; your experience enables you to see something there that I don't, so I want to understand what I am not seeing)...

Also, is the usermod you backfitted available? I'm interested in looking at it and seeing what I can learn.

At the present time if I were updating the SYSCPK page I would probably simply remove the integration instructions/program and leave it to each individual to integrate it as they see fit.

I would respectfully ask that you not remove those. Yes, probably the majority of the consumers of SYSCPK are MVS professionals, and they know how to do what needs doing. But...

Some of us are neophytes; we know how to administer systems, just that MVS is not one of them (I was hell on wheels with RSX-11M, VMS, BSD, and Linux, but not so much MVS), and your instructions were the only thing that enabled me to get the SYSCPK going. There was *no* way I was going to know how to connect the catalogs or get JES2 to pay attention to SYSC.PROCLIB without those instructions... and now I have a template to work from when I am doing similar stuff, and most importantly, I UNDERSTAND HOW THE PIECES FIT TOGETHER, HOW THEY BREAK, HOW TO FIX THEM.

Yes, I also stubbed my toe because the JES2 setup on my system was different than your instructions were written for, but now I understand how JES2 is started, where it gets it's parameters from, how to add proclibs to it, what COMMNDxx is for, and how to use ZZSA... and in the process of reading the manuals to learn some of that, I learned a lot more!

You providing explicit instructions WITH EXPLANATIONS has helped me a great deal.

On 6/25/20 4:40 PM, Doug Wegscheid wrote:

On Thu, Jun 25, 2020 at 02:08 PM, Jay Moseley wrote:
It sounds like you prefer the Dynamic Proclib approach, so that is
probably what you should use and integrate the load modules,
procedures and library PDSes into your system using the method you
prefer. I have tried Brian Westerman's Dynamic Proclib and didn't
particularly care for it, although it is included on another page at
my site and I heartily recommend it to anyone for whom that approach
appeals to them and works for them. I have also backfitted a Usermod
to allow SYSC.LINKLIB to be concatenated into the Link List, and it
works great for me on my system.
Jay, what didn't you like about the dynamic proclib? (I'm not trying to spark an argument; your experience enables you to see something there that I don't, so I want to understand what I am not seeing)...

Doug,

I don't remember anything specific, but it just wasn't something I thought I would use. I set up the SMP install for it because it was pointed out to me that it could be done and there was interest in it. I put it into a form where it installed from source rather than object and installed it. I created a test proclib and played with it for a while. But I just couldn't see how it added much for my own use. I already have the capability of using a JOBPARM proclib statement: /*JOBPARM PROCLIB=PROCnn in the rare case I would need to do something like this. I bricked my MVS system several times last month and one of the times I was rebuilding I just decided to leave it off.

As for killing an MVS, I do that occasionally. I have some periodic 'daily' backups of a few datasets that I might be interested in. But every change that I make to my system that I intend to keep I also make an entry in one of the 'setup' jobstream datasets I keep in a 3380-E volume. So most of the time when I restore I start from a copy of a newly generated MVS system and submit 2-3 jobstreams to get my system back the way it was. Each of the jobstreams I submit are just IEBGENER jobs that copy more jobstreams into the internal reader. At most it takes 30 minutes. It is good practice for ensuring my customization jobstreams work.

Also, is the usermod you backfitted available? I'm interested in looking at it and seeing what I can learn.

It is on a page that contains some usermods that have come up since I revised the MVS installation instructions. This entire page was created at the suggestion of someone else, as has much that is on my site. Someone asks for it and I try to figure out how to do it, then explain what I did and, if I can, why.

This particular usermod was reworked from one found on CBT that originated in 1981. I found several later versions, but this one was closest to our version. Current z/OS, and maybe even late OS/390, versions don't need this as they don't require the Link List libraries to be catalogued in the master catalog.

At the present time if I were updating the SYSCPK page I would
probably simply remove the integration instructions/program and
leave it to each individual to integrate it as they see fit.
I would respectfully ask that you not remove those. Yes, probably the majority of the consumers of SYSCPK are MVS professionals, and they know how to do what needs doing. But...

Well, I was equating it with the VSAMIO installation instructions. When I got into revising them it became a mess. Since the complete VSAMIO source libraries are on SYSCPK and the modules are in SYSC.LINKLIB ready to link into user COBOL and Pl/1 programs, I decided to just scrap the installation.

I guess I will revisit SYSCPK when I have time and see what can be revised. As I said, this has not been looked at since 2015 when it was created, other than to add new version information. I had Phil prodding me back then to even do it and it was the last thing I did before life hit me between the eyes with a couple of large setbacks. I didn't get back on an even keel until 2017 and near the end of that year I got a baby to raise ... just before I went onto Medicare. I wouldn't trade him for anything, but he takes a big chunk of my time now.

Some of us are neophytes; we know how to administer systems, just that MVS is not one of them (I was hell on wheels with RSX-11M, VMS, BSD, and Linux, but not so much MVS), and your instructions were the only thing that enabled me to get the SYSCPK going. There was *no* way I was going to know how to connect the catalogs or get JES2 to pay attention to SYSC.PROCLIB without those instructions... and now I have a template to work from when I am doing similar stuff, and most importantly, I UNDERSTAND HOW THE PIECES FIT TOGETHER, HOW THEY BREAK, HOW TO FIX THEM.
Yes, I also stubbed my toe because the JES2 setup on my system was different than your instructions were written for, but now I understand how JES2 is started, where it gets it's parameters from, how to add proclibs to it, what COMMNDxx is for, and how to use ZZSA... and in the process of reading the manuals to learn some of that, I learned a lot more!
You providing explicit instructions WITH EXPLANATIONS has helped me a great deal.

That is the primary intent of my site. It originally started as sort of a 'scratchpad' for my own private use when Volker, Wolfgang, Jim Morrison, Bertus Bekker, Jay Maynard, and at least a dozen other people were trying to get an MVS system to build under Hercules. In fact, it originally was mostly MVT stuff. I never intended to have a 'product' like the Turnkey systems, but to have a place to guide people who were interested into building their own system and learning things. I wouldn't ever claim I know everything, just a little bit about everything and a desire to get things to work. Jim once wrote me that I seemed to have a knack for 'packaging' and I guess I let it go to my head.

Jay

开云体育

On Thu, Jun 25, 2020 at 02:08 PM, Jay Moseley wrote:

It sounds like you prefer the Dynamic Proclib approach, so that is probably what you should use and integrate the load modules, procedures and library PDSes into your system using the method you prefer. I have tried Brian Westerman's Dynamic Proclib and didn't particularly care for it, although it is included on another page at my site and I heartily recommend it to anyone for whom that approach appeals to them and works for them. I have also backfitted a Usermod to allow SYSC.LINKLIB to be concatenated into the Link List, and it works great for me on my system.

Jay, what didn't you like about the dynamic proclib? (I'm not trying to spark an argument; your experience enables you to see something there that I don't, so I want to understand what I am not seeing)...

Also, is the usermod you backfitted available? I'm interested in looking at it and seeing what I can learn.

At the present time if I were updating the SYSCPK page I would probably simply remove the integration instructions/program and leave it to each individual to integrate it as they see fit.

I would respectfully ask that you not remove those. Yes, probably the majority of the consumers of SYSCPK are MVS professionals, and they know how to do what needs doing. But...

Some of us are neophytes; we know how to administer systems, just that MVS is not one of them (I was hell on wheels with RSX-11M, VMS, BSD, and Linux, but not so much MVS), and your instructions were the only thing that enabled me to get the SYSCPK going. There was *no* way I was going to know how to connect the catalogs or get JES2 to pay attention to SYSC.PROCLIB without those instructions... and now I have a template to work from when I am doing similar stuff, and most importantly, I UNDERSTAND HOW THE PIECES FIT TOGETHER, HOW THEY BREAK, HOW TO FIX THEM.

Yes, I also stubbed my toe because the JES2 setup on my system was different than your instructions were written for, but now I understand how JES2 is started, where it gets it's parameters from, how to add proclibs to it, what COMMNDxx is for, and how to use ZZSA... and in the process of reading the manuals to learn some of that, I learned a lot more!

You providing explicit instructions WITH EXPLANATIONS has helped me a great deal.

_.

Jay,

If your choices are listen to Doug and ignore me, or pay attention to me and purge stuff ... Listen to Doug.

-ahd-

-- 
Drew Derbyshire

"WAAF, home of the million dollar guarantee. You give us a million
 dollars, we'll play any song you want. Guaranteed."

On Thu, 25 Jun 2020, Doug Wegscheid wrote:

I would respectfully ask that you not remove those. Yes, probably the majority of the consumers of SYSCPK are MVS professionals, and they know how to do what needs doing. But...
Some of us are neophytes; we know how to administer systems, just that MVS is not one of them (I was hell on wheels with RSX-11M, VMS, BSD, and Linux, but not so much MVS), and your instructions were the only thing that enabled me to get the SYSCPK going. There was *no* way I was going to know how to connect the catalogs or get JES2 to pay attention to SYSC.PROCLIB without those instructions... and now I have a template to work from when I am doing similar stuff, and most importantly, I UNDERSTAND HOW THE PIECES FIT TOGETHER, HOW THEY BREAK, HOW TO FIX THEM.

I would join to this request and I completely share this statement.

I'm an element of the 'set' really well defined within this statement

{ "we know how to administer systems, just that MVS is not one of them" }

as I began as naive as it is possible to be about MVS.

If I may add my personal 2 cents, while I started playing
with TK4-, a wonderful ready to use MVS environment, where
I really learned some bit about MVS was following the Jay
Moseley instructions to build a new system, starting
from scratch.

I guess the best way to express my feeling is quoting an
english proverb

"If you give a man a fish he is hungry again in an hour.
If you teach him to catch a fish you do him a good turn."

If I can, I wish to thank once again Jay Moseley for
his instructions and the time he spent on his MVS site.

Peppe.

开云体育

I guess the best way to express my feeling is quoting an
english proverb

?"If you give a man a fish he is hungry again in an hour.
? If you teach him to catch a fish you do him a good turn."

Indeed it's one of minor things I don't like about TK4-, that it doesn't teach.

-ahd-

p.s. Old proverb known to valets of feline overlords:

"If you give a cat a fish, he'll eat for a day.
?If you teach a cat to fish,
??? he'll sit in his boat pouting
??? ??? because no one gave hm more fish."

-- 
Drew Derbyshire

 Surely, not EVERYONE was Kung Fu Fighting

On 6/26/20 1:10 AM, Giuseppe Vitillaro wrote:

On Thu, 25 Jun 2020, Doug Wegscheid wrote:

I would respectfully ask that you not remove those. Yes, probably the majority of the consumers of SYSCPK are MVS professionals, and they know how to do what needs doing. But...

Some of us are neophytes; we know how to administer systems, just that MVS is not one of them (I was hell on wheels with RSX-11M, VMS, BSD, and Linux, but not so much MVS), and your instructions were the only thing that enabled me to get the SYSCPK going. There was *no* way I was going to know how to connect the catalogs or get JES2 to pay attention to SYSC.PROCLIB without those instructions... and now I have a template to work from when I am doing similar stuff, and most importantly, I UNDERSTAND HOW THE PIECES FIT TOGETHER, HOW THEY BREAK, HOW TO FIX THEM.

How to fix MVS?? IPL VM.? :-)

MVS versus VM is like ISO networking going up against TCP/IP.

--
Drew Derbyshire

"May the Force be with you!" -- Luke Skywalker