Discussion:
[H390-MVS] Enable "ST *" for REVOUT?
'Matthew R. Wilson' mwilson@mattwilson.org [H390-MVS]
2018-09-02 05:33:36 UTC
Permalink
Hello again --

Almost have my custom-built MVS 3.8 system set up with the features from
TK4- I want (why not just use TK4-? To learn how to do things myself, of
course! Surely most folks on this list understand that motivation), but one
question remains...

When using REVOUT on TK4- (either from REVIEW's 3.8 option or starting
REVOUT from TSO), I have an option to use "ST *" to see the status of all
jobs.

On my system, I don't get the hint at the bottom of REVOUT to do that, and
ST * doesn't work.

My research has led me to usermod SLB0001 that provides user exit IKJEFF53.
Now from TSO my user is permitted to view arbitrary job names with STATUS
and OUTPUT. I assume that's part of the puzzle to enable REVIEW to show me
output from other jobs. And, indeed, if I know the specific job name I can
do "ST jobname" in REVOUT and view the held output.

But the "ST *" command still isn't working for me. (I also note that REVOUT
on TK4- has a couple extra columns, QUEUE and EXEC).

Are there other usermods I need to enable that functionality? Or something
else?

As always, thank you for your help!

-Matthew
jimruddy1953@yahoo.com [H390-MVS]
2018-09-02 16:44:28 UTC
Permalink
Using ISPF, the Utilities panel (ISPUTILS) invokes the Review output program via CMD(REVOUT *). I ran a test where I changed it to CMD(REVOUT) and saw only the output from the TSOID I was running with and " (USE ST * FOR ALL JOBS) 7144K FREE" at the bottom of the screen. If you are building a multi-user system, you might want it to work that way but I personally like the automatic "ST *" via ISPF.


Jim
Gregg Levine gregg.drwho8@gmail.com [H390-MVS]
2018-09-02 17:03:24 UTC
Permalink
Hello!
Makes sense. A suggestion? Create and upload a FAQ containing
everything you've encountered on this issue.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."
Just had a look at TK4.8
selecting 3.8 does NOT show any guidance what so ever on my system ..
going to try again from the top without ISPF ..
Arr, going in with 1.3.8 does show it (see below) but not via ISPF,
odd a wee buglet methinks.
with just one job as just started MVS38
--
(USE ST * FOR ALL JOBS) 6896K FREE
--
3.8
Gives the 'ST *' pattern any way again no extra comments or help etc.
Have a look at the docs from TK4 along with the updates docs which might
well help and yes there are a lot of MODS applied in TK4 with more for
KICKS, RAKF, ISPF for each to work plus the GP system one's.
Vince
Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
Hello again --
Almost have my custom-built MVS 3.8 system set up with the features
from TK4- I want (why not just use TK4-? To learn how to do things
myself, of course! Surely most folks on this list understand that
motivation), but one question remains...
When using REVOUT on TK4- (either from REVIEW's 3.8 option or starting
REVOUT from TSO), I have an option to use "ST *" to see the status of
all jobs.
On my system, I don't get the hint at the bottom of REVOUT to do that,
and ST * doesn't work.
My research has led me to usermod SLB0001 that provides user exit
IKJEFF53. Now from TSO my user is permitted to view arbitrary job
names with STATUS and OUTPUT. I assume that's part of the puzzle to
enable REVIEW to show me output from other jobs. And, indeed, if I
know the specific job name I can do "ST jobname" in REVOUT and view
the held output.
But the "ST *" command still isn't working for me. (I also note that
REVOUT on TK4- has a couple extra columns, QUEUE and EXEC).
Are there other usermods I need to enable that functionality? Or
something else?
As always, thank you for your help!
------------------------------------
------------------------------------
This message is sponsored by Leopards Need Trees a big cat united club.
winkelmann@id.ethz.ch [H390-MVS]
2018-09-02 22:35:51 UTC
Permalink
Hi All


it should be noted, that creating a general (i.e. not TK4- specific) documentation of this behavior will be more complex as it seems at first sight, as many components are part of the game, and all can be configured differently on the various system builds that are around. The main things that come to mind are:

OPER attribute of the TSO user: This controls, whether the TSO FIB commands will act only on jobs with names starting with the TSO userid or not. On TK4- the default users HERC01 and HERC02 have the OPER attribute, HERC03 and HERC04 don't have it.

RFE REVOUT FIB ON or OFF: Controls whether the spool is read directly by REVOUT or via the TSO OUTPUT command. As the default is off, normally all jobs' output can be read, regardless of the user having the OPER attribute or not, which I consider being a minor security flaw on multi user systems. At least it comes as a surprise that on TK4- users HERC03 and HERC04 can read all spool output through menu 3.8, despite not having OPER.
Settings in IKJEFTE2: RFE and ISPF should be listed, otherwise you may be in for surprises (not only with menu 3.8). And both should come from authorized libraries and have AC=1 (RFE has this as default, ISPF not).

And probably more that I don't think of spontaneously



Cheers
JÃŒrgen

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

Hello!
Makes sense. A suggestion? Create and upload a FAQ containing
everything you've encountered on this issue.
-----
Gregg C Levine ***@... mailto:***@...
"This signature fought the Time Wars, time and again."
Just had a look at TK4.8
selecting 3.8 does NOT show any guidance what so ever on my system ..
going to try again from the top without ISPF ..
Arr, going in with 1.3.8 does show it (see below) but not via ISPF,
odd a wee buglet methinks.
with just one job as just started MVS38
--
(USE ST * FOR ALL JOBS) 6896K FREE
--
3.8
Gives the 'ST *' pattern any way again no extra comments or help etc.
Have a look at the docs from TK4 along with the updates docs which might
well help and yes there are a lot of MODS applied in TK4 with more for
KICKS, RAKF, ISPF for each to work plus the GP system one's.
Vince
Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
Hello again --
Almost have my custom-built MVS 3.8 system set up with the features
from TK4- I want (why not just use TK4-? To learn how to do things
myself, of course! Surely most folks on this list understand that
motivation), but one question remains...
When using REVOUT on TK4- (either from REVIEW's 3.8 option or starting
REVOUT from TSO), I have an option to use "ST *" to see the status of
all jobs.
On my system, I don't get the hint at the bottom of REVOUT to do that,
and ST * doesn't work.
My research has led me to usermod SLB0001 that provides user exit
IKJEFF53. Now from TSO my user is permitted to view arbitrary job
names with STATUS and OUTPUT. I assume that's part of the puzzle to
enable REVIEW to show me output from other jobs. And, indeed, if I
know the specific job name I can do "ST jobname" in REVOUT and view
the held output.
But the "ST *" command still isn't working for me. (I also note that
REVOUT on TK4- has a couple extra columns, QUEUE and EXEC).
Are there other usermods I need to enable that functionality? Or
something else?
As always, thank you for your help!
------------------------------------
------------------------------------
This message is sponsored by Leopards Need Trees a big cat united club.
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-09-06 00:13:29 UTC
Permalink
This post might be inappropriate. Click to display it.
pricgren pricgren@yahoo.com [H390-MVS]
2018-09-06 08:59:03 UTC
Permalink
Isn't the id of the user available in some control block which can be
used for such filtering?
No.

Cheers,
Greg
Gerhard Postpischil gerhardp@charter.net [H390-MVS]
2018-09-06 12:14:34 UTC
Permalink
Isn't the id of the user available in some control block which can be
used for such filtering?
No.
Many installations use the account number, and that's widely available.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com
'Shelby Beach' shelby.beach@comcast.net [H390-MVS]
2018-09-06 19:39:09 UTC
Permalink
If you want such filtering on MVS 3.8 you'll need JES3 ! JES2 didn't get
around to it until later releases of z/OS.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Thursday, September 06, 2018 1:59 AM
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Userid and Jobnames
Isn't the id of the user available in some control block which can be
used for such filtering?
No.

Cheers,
Greg
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-09-07 00:53:21 UTC
Permalink
I don't really want such a filtering but was puzzled about using jobname
for this purpose. It would make some sense if users could not submit jobs
except with jobnames starting with their userid but in absence of that it
doesn't really achieve anything. I'm glad there is ST * !
Khalid

On Thu, 06 Sep 2018 14:39:09 -0500, 'Shelby Beach'
Post by 'Shelby Beach' ***@comcast.net [H390-MVS]
If you want such filtering on MVS 3.8 you'll need JES3 ! JES2 didn't get
around to it until later >releases of z/OS.
Shelby
Post by 'Shelby Beach' ***@comcast.net [H390-MVS]
Thursday, September 06, 2018 1:59 AM
Subject: Re: [H390-MVS] Userid and Jobnames
Isn't the id of the user available in some control block which can be
used for such filtering?
No.
Cheers,
Greg
--Using Opera's mail client: http://www.opera.com/mail/
'Shelby Beach' shelby.beach@comcast.net [H390-MVS]
2018-09-07 01:26:01 UTC
Permalink
Khalid,

Just a bit of additional info... this whole "userid+char" thing goes all the
way back to when TSO was first introduced in MVT. At that time, there was
not even a requirement to have a job entry subsystem (HASP or ASP).

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Thursday, September 06, 2018 5:53 PM
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Userid and Jobnames






I don't really want such a filtering but was puzzled about using jobname for
this purpose. It would make some sense if users could not submit jobs except
with jobnames starting with their userid but in absence of that it doesn't
really achieve anything. I'm glad there is ST * !
Khalid

On Thu, 06 Sep 2018 14:39:09 -0500, 'Shelby Beach' ***@comcast.net
[H390-MVS] <H390-***@yahoogroups.com> wrote:





If you want such filtering on MVS 3.8 you'll need JES3 ! JES2 didn't get
around to it until later releases of z/OS.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Thursday, September 06, 2018 1:59 AM
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Userid and Jobnames
Isn't the id of the user available in some control block which can be
used for such filtering?
No.

Cheers,
Greg
--
Using Opera's mail client: http://www.opera.com/mail/
'M. Khalid Khan' khalidxyz@gmail.com [H390-MVS]
2018-09-07 00:57:41 UTC
Permalink
So we don't really know whose jobs these are but enforce some access rules
anyway ... oh well.
Regards
Khalid
Post by pricgren ***@yahoo.com [H390-MVS]
Isn't the id of the user available in some control block which can be
used for such filtering?
No.
Cheers,
Greg
------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
Tom Bottomley t.bottomley@yahoo.co.uk [H390-MVS]
2018-09-07 04:16:00 UTC
Permalink
This works on recent opsys to get the Userid, not sure about the older ones.
Prelim DSECTS, no copy, these are macro's
   IHAPSA   IHAASCB   IHAASXB   IHAACEE

Code ( no USING necessary )
L       R15,PSAOLD-PSA                 Work Register R15L       R15,ASCBASXB-ASCB(R15)L       R15,ASXBENV-ASXB(R15)LTR  R15,R15BZ    NOACEESLR  R5,R5                                     Work Register R5IC     R5,ACEEUSRL-ACEE(,R15)LA     R6,ACEEUSRI-ACEE(,R15)  Work Register R6BCTR R5,0MVC USERNAME(0),0(R6)EX    R5,*-6
Regards,Tom ( Greybeard )
On Thursday, 6 September 2018, 16:59:18 GMT+8, pricgren ***@yahoo.com [H390-MVS] <H390-***@yahoogroups.com> wrote:

 
Isn't the id of the user available in some control block which can be
used for such filtering?
No.

Cheers,
Greg
Gerhard Postpischil gerhardp@charter.net [H390-MVS]
2018-09-07 11:42:05 UTC
Permalink
On 9/7/2018 12:16 AM, Tom Bottomley ***@yahoo.co.uk [H390-MVS]
wrote:> This works on recent opsys to get the Userid, not sure about the
older ones.
This requires RACF; not sure about RAKF. In any case, the user id is the
jobname field in the TIOT, and that's easily accessible.

Also it does not solve the problem of how a TSO program can determine
the user id for an arbitrary job. With some local changes, the user id
could be placed into the SMF user field, but even so the querant would
need to be privileged, test for environment (JES2, JES3, start job), and
find the JMR in the job's address space (when running), or the subsystem
control block (e.g., $JCT).

Also current systems support an 8-character user id, so additional code
is needed.

Gerhard Postpischil
Bradford, VT
Post by Tom Bottomley ***@yahoo.co.uk [H390-MVS]
Prelim DSECTS, no copy, these are macro's
   IHAPSA
   IHAASCB
   IHAASXB
   IHAACEE
Code ( no USING necessary )
L       R15,PSAOLD-PSA                 Work Register R15
L       R15,ASCBASXB-ASCB(R15)
L       R15,ASXBENV-ASXB(R15)
LTR  R15,R15
BZ    NOACEE
SLR  R5,R5                                     Work Register R5
IC     R5,ACEEUSRL-ACEE(,R15)
LA     R6,ACEEUSRI-ACEE(,R15)  Work Register R6
BCTR R5,0
MVC USERNAME(0),0(R6)
EX    R5,*-6
Regards,
Tom ( Greybeard )
---
This email has been checked for viruses by AVG.
https://www.avg.com

pricgren pricgren@yahoo.com [H390-MVS]
2018-09-03 11:40:10 UTC
Permalink
Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
When using REVOUT on TK4- (either from REVIEW's 3.8 option or starting
REVOUT from TSO), I have an option to use "ST *" to see the status of
all jobs.
On my system, I don't get the hint at the bottom of REVOUT to do that,
and ST * doesn't work.
Hi Matt,

In a way, good.  The hint is supposed to appear if it is available, and
not appear if it is not available.  Your observations seem to indicate
the this consistency persists.

Before employing direct JES2 checkpoint and spool I/O, REVOUT checks that
- the system is MVS/370
- the MVS/370 is pre-MVS/SE(2)
- the primary subsystem is JES2 (in type, not in name)

Go into IMON option M, using
IM M
from READY, or however else is convenient, and scroll down a bit to the
subsystem list.  On my system, the first entry I have is:
JES2  SSCVT 00B7DFC0  ID 02  SSVT 00B6EB80  SS-USE 00000000

Look at your entry for JES2, and note the ID value.

If it is not 02, then you need to apply the TJES801 usermod from Kevin
Leonard's usermod web page at
http://www.j76.org/vs2/usermods.html

This usermod will alter JES2 to set the identifier in its SSCT. This
allows software (such as REVOUT) to identify the subsystem as JES2
without regard for the name of the subsystem (because it does not
actually have to be called JES2).

The direct I/O path for REVOUT was lifted from QUEUE, but whereas MVS
control blocks are pretty stable, JES2 morphs with each release, and so
the direct I/O logic has to know about the appropriate release level. 
Since we are not likely to get a later JES2 (NJE anyone?) for this
system level, I thought coding for this release would prove useful.  It
certainly reduces the response time for the printouts I look at.

Regarding security, on a real system, general users would probably not
be able to read the JES2 checkpoint and spool, and so would not be able
to use the direct I/O logic path of REVOUT, or use QUEUE at all.  IBM's
SDSF program product uses privileged code to access the spool for
anyone, but also provides configurable command menus and SAF checking as
ways to restrict access to specific functions and job data.

Cheers,
Greg
'Matthew R. Wilson' mwilson@mattwilson.org [H390-MVS]
2018-09-03 21:33:06 UTC
Permalink
JES2  SSCVT 00B7DFC0  ID 02  SSVT 00B6EB80  SS-USE 00000000
Look at your entry for JES2, and note the ID value.
If it is not 02, then you need to apply the TJES801 usermod from Kevin
Leonard's usermod web page at
http://www.j76.org/vs2/usermods.html
Ah, yes, on my system it's 00, and I don't have TJES801 applied. I'm getting
assembler errors (hundreds of `undefined symbol` and other errors) when
doing the APPLY...but I'll try to work on that and see if I can figure out
why.

And yes -- "st *" works as expected when I use QUEUE, so if I can get this
usermod installed it sounds like I'll then have the same behavior in RFE.

Thank you again!

-Matthew
Laddie Hanus laddiehanus@yahoo.com [H390-MVS]
2018-09-03 22:22:27 UTC
Permalink
Does the syslib in your SMP proc have SYS1.HASPSRC in the concatenation?
If you get missing macros starting with $ this is probably the issue. I
dont have the ptf so I dont know for sure.

Laddie Hanus
Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
JES2ᅵ SSCVT 00B7DFC0ᅵ ID 02ᅵ SSVT 00B6EB80ᅵ SS-USE 00000000
Look at your entry for JES2, and note the ID value.
If it is not 02, then you need to apply the TJES801 usermod from Kevin
Leonard's usermod web page at
http://www.j76.org/vs2/usermods.html
Ah, yes, on my system it's 00, and I don't have TJES801 applied. I'm getting
assembler errors (hundreds of `undefined symbol` and other errors) when
doing the APPLY...but I'll try to work on that and see if I can figure out
why.
And yes -- "st *" works as expected when I use QUEUE, so if I can get this
usermod installed it sounds like I'll then have the same behavior in RFE.
Thank you again!
-Matthew
'Matthew R. Wilson' mwilson@mattwilson.org [H390-MVS]
2018-09-03 22:40:03 UTC
Permalink
Does the syslib in your SMP proc have SYS1.HASPSRC in the concatenation? If
you get missing macros starting with $ this is probably the issue. I dont
have the ptf so I dont know for sure.
Yep, that was one part of my problem I discovered. My SMPAPP proc didn't have
SYS1.HASPSRC in the SYSLIB concatenation. Added it, and am now down to only two
undefined symbols: SSCTJES2 and SSCTSSID -- the two that the usermod is trying
to change.

Searching through other PTFs available to me, it looks like UY02859 is what
adds those two symbols, so should probably be added as a prereq to the
TJES801 usermod.

Now I'm working on getting UY02859 installed; I think I messed up by APPLYing
it instead of ACCEPTing it... I'v been applying usermods but perhaps I should
be accepting PTFs? Not exactly sure what went wrong; the apply succeeded but
now there doesn't seem to be any trace if it on the system.

So I'm going to retrace my steps and make sure everything really did work,
but I think between adding HASPSRC and getting UY02859 properly installed
I'll resolve all of the assembly errors and be up and running.

Thanks,
Matthew
'Matthew R. Wilson' mwilson@mattwilson.org [H390-MVS]
2018-09-03 23:54:04 UTC
Permalink
Success! Thanks for everyone's help. My REVIEW output list now has a
functioning "ST *" option to show all jobs.

For folks who run across the thread in the future, summary of changes
from a mostly unmodified MVS 3.8 system installed with Jay Moseley's
instructions:

1. Update SMP2.PROCLIB(SMPAPP) to include SYS1.HASPSRC in the SYSLIB
concatenation.

2. APPLY the PTFs UY02859 (adds SSCTJES2 and SSCTSSID symbols)
and UZ77164 (prerequisite for TJES801 usermod). In the Moseley system
these were already RECEIVEd but were not applied to the system.

3. Run the JCL for usermod TJES801 from http://www.j76.org/vs2/usermods.html.

Re-IPL the system, 'R 0,CLPA' at startup, and then as Greg explained REVIEW/
REVOUT will know that it's dealing with JES2 and operate on the spools
directly to offer, among other things, the 'ST *' capability.

Thanks,
Matthew
Giuseppe Vitillaro giuseppe@vitillaro.org [H390-MVS]
2018-09-04 08:12:59 UTC
Permalink
Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
Does the syslib in your SMP proc have SYS1.HASPSRC in the concatenation? If
you get missing macros starting with $ this is probably the issue. I dont
have the ptf so I dont know for sure.
Yep, that was one part of my problem I discovered. My SMPAPP proc didn't have
SYS1.HASPSRC in the SYSLIB concatenation. Added it, and am now down to only two
undefined symbols: SSCTJES2 and SSCTSSID -- the two that the usermod is trying
to change.
Searching through other PTFs available to me, it looks like UY02859 is what
adds those two symbols, so should probably be added as a prereq to the
TJES801 usermod.
Now I'm working on getting UY02859 installed; I think I messed up by APPLYing
it instead of ACCEPTing it... I'v been applying usermods but perhaps I should
be accepting PTFs? Not exactly sure what went wrong; the apply succeeded but
now there doesn't seem to be any trace if it on the system.
So I'm going to retrace my steps and make sure everything really did work,
but I think between adding HASPSRC and getting UY02859 properly installed
I'll resolve all of the assembly errors and be up and running.
Thanks,
Matthew
Yep, again from my notes, TJES801 has UY02859 as a prereq.

If I remeber correctly UY02859 is a nightmare to install
if ALL the patches on the Volker ptfs tape are not installed.

My SYSGEN came from the Moseley ptfs tape and UY02859
was definitely NOT easy to install.

I ended installing following the Moseley guidelines
and SYSGEN, but I used the Volker ptfs tape instead
of the Moseley one.

What I got is neither a TK3, neither a Moseley ;-)

But UY02859 is easier to install this way and REVOUT
works nicely once TJES801 is installed.

Peppe.
pricgren pricgren@yahoo.com [H390-MVS]
2018-09-04 13:31:28 UTC
Permalink
Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
Now I'm working on getting UY02859 installed; I think I messed up by APPLYing
it instead of ACCEPTing it... I'v been applying usermods but perhaps I should
be accepting PTFs?
Probably worth mentioning that in the normal case, when processing PTFs,
one does the APPLY before the ACCEPT.

(One notable exception is if preparing for a SYSGEN of a new system
level on an older level such as a starter system, where ACCEPT NOAPPLY
is done to bring the DLIBs up to date before doing the SYSGEN which
builds a new system from the distribution libraries.)

Also it needs to be remembered that when macros have no system (or
target) library (such as macros from HASPSRC and AMODGEN at this MVS
level), they live in SMPMTS until ACCEPT time when they are moved to
their distribution library.� For source-maintained elements with no
SYSLIB (such as HASPSRC source members), updated source lives in SMPSTS
until ACCEPT time.

For this reason, SMPMTS should be ahead of libraries such as AMODGEN and
HASPSRC in the SYSLIB concatenation, not only for SMP but sometimes
(depending on what you are assembling) also for non-SMP assembles.

Again, just background factoids for those who might need to find out
such things...

Cheers,
Greg



------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
Giuseppe Vitillaro giuseppe@vitillaro.org [H390-MVS]
2018-09-04 15:11:17 UTC
Permalink
Post by pricgren ***@yahoo.com [H390-MVS]
Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
Now I'm working on getting UY02859 installed; I think I messed up by APPLYing
it instead of ACCEPTing it... I'v been applying usermods but perhaps I should
be accepting PTFs?
Probably worth mentioning that in the normal case, when processing PTFs,
one does the APPLY before the ACCEPT.
(One notable exception is if preparing for a SYSGEN of a new system
level on an older level such as a starter system, where ACCEPT NOAPPLY
is done to bring the DLIBs up to date before doing the SYSGEN which
builds a new system from the distribution libraries.)
Also it needs to be remembered that when macros have no system (or
target) library (such as macros from HASPSRC and AMODGEN at this MVS
level), they live in SMPMTS until ACCEPT time when they are moved to
their distribution library.ᅵ For source-maintained elements with no
SYSLIB (such as HASPSRC source members), updated source lives in SMPSTS
until ACCEPT time.
For this reason, SMPMTS should be ahead of libraries such as AMODGEN and
HASPSRC in the SYSLIB concatenation, not only for SMP but sometimes
(depending on what you are assembling) also for non-SMP assembles.
Again, just background factoids for those who might need to find out
such things...
Cheers,
Greg
MVS3.8j SMP is one of the most complex things
I met in my digital life, even the documentation
is not easy to read.

I wonder how this mess is managed in a modern Z/OS.

Peppe.
Gregg Levine gregg.drwho8@gmail.com [H390-MVS]
2018-09-05 02:23:53 UTC
Permalink
Hello!
Very carefully. And the documentation is even more complicated.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 4, 2018 at 11:11 AM, Giuseppe Vitillaro
Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
Post by pricgren ***@yahoo.com [H390-MVS]
Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
Now I'm working on getting UY02859 installed; I think I messed up by APPLYing
it instead of ACCEPTing it... I'v been applying usermods but perhaps I should
be accepting PTFs?
Probably worth mentioning that in the normal case, when processing PTFs,
one does the APPLY before the ACCEPT.
(One notable exception is if preparing for a SYSGEN of a new system
level on an older level such as a starter system, where ACCEPT NOAPPLY
is done to bring the DLIBs up to date before doing the SYSGEN which
builds a new system from the distribution libraries.)
Also it needs to be remembered that when macros have no system (or
target) library (such as macros from HASPSRC and AMODGEN at this MVS
level), they live in SMPMTS until ACCEPT time when they are moved to
their distribution library.ᅵ For source-maintained elements with no
SYSLIB (such as HASPSRC source members), updated source lives in SMPSTS
until ACCEPT time.
For this reason, SMPMTS should be ahead of libraries such as AMODGEN and
HASPSRC in the SYSLIB concatenation, not only for SMP but sometimes
(depending on what you are assembling) also for non-SMP assembles.
Again, just background factoids for those who might need to find out
such things...
Cheers,
Greg
MVS3.8j SMP is one of the most complex things
I met in my digital life, even the documentation
is not easy to read.
I wonder how this mess is managed in a modern Z/OS.
Peppe.
------------------------------------
------------------------------------
The previous message is being sponsored by Cheetahs Run Fast with
Expensive Sneakers a big cat sponsor group.
Gerhard Postpischil gerhardp@charter.net [H390-MVS]
2018-09-05 01:36:39 UTC
Permalink
Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
MVS3.8j SMP is one of the most complex things
I met in my digital life, even the documentation
is not easy to read.
I wonder how this mess is managed in a modern Z/OS.
It isn't. AFAIK, the current version of SMP is (almost?) complete rewrite.

Gerhard Postpischil
Bradford, VT

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



------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
pricgren pricgren@yahoo.com [H390-MVS]
2018-09-05 08:48:25 UTC
Permalink
Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
I wonder how this mess is managed in a modern Z/OS.
SMP/E replaces the CDS/CRQ (and ACDS/ACRQ) combo with "zones".

Instead of using a PDS with cylinders and cylinders of directory blocks,
VSAM data sets are used, and they must have a low-level qualifier of
CSI.� A CSI (Consolidated Software Inventory) VSAM cluster may contain
one or more zones.

RECEIVE/REJECT processing updates the GLOBAL zone (which is always
called GLOBAL) and SMPPTS.
APPLY/RESTORE processing updates the TARGET zone (which you can name).
ACCEPT processing updates the DLIB zone (which you can name).

Target zones are related to a specific DLIB zone, but you can have
multiple target zones per DLIB zone.
The GLOBAL zone has the zoneindexes which link the variously named
target & DLIB zones to VSAM data sets.
You can name the GLOBAL zone in the program parameter, or allocate it to
the SMPCSI DD.
You can populate DDDEF entries (for each zone) so you don't have to
supply a DD to each syslib and dlib.
SMP/E prints a DD report showing data� sets and volumes etc. used.

Data sets which still exist in SMP/E include the SCDS (strange, eh?),
MTS, STS and the PTS which only gets 1 member per SYSMOD - the one
containing the input MCS.

The LTS (Load Temporary Store) is new and must be a PDSE (so it can
handle program objects).

And there's new stuff for doing a RECEIVE from the web, and for APPLY to
deliver elements to UNIX files instead of MVS data sets. Of course, with
tapes being bypassed RECEIVE can now process relfiles on disk.� IBM no
longer ships maintenance or products on tape.

While RECEIVE won't receive the same SYSMOD more than once (unless the
REWORK date is later) it does check that the SYSMOD is present in both
the GLOBAL zone and SMPPTS.� An easy way of repeating a RECEIVE without
a REJECT is to delete the MCS member from SMPPTS.

The DIS (Directory In Storage) operand has disappeared, but you have to
say which zone the operation is for with a
SET command.� While GROUP will still look "backward" for pre-reqs,
GROUPEXTEND will also look "forward" for later maintenance which
supersedes missing pre-reqs and apply that as well.

There's a whole ISPF application for admin and queries, a programmable
API, and lots more stuff since I stopped sysprogging. Yep, it's more
complicated, but also more powerful and much more efficient.� But major
concepts are unchanged, and MCS is downward compatible.

The doc is online so if you want to get a feel for the differences, go
have a look.

But at the end of the day, it is still RECEIVE, APPLY, ACCEPT.
:)


And now, some exhibits from the museum... (bail out now if you don't
like JCL - or SMP)

JCL from the 90s I found, back when TCPIP was not part of MVS/ESA V4:
//RECEIVE EXEC PGM=GIMSMP,
//������������ PARM='CSI=MVSSMPE.GLOBAL.CSI,LANGUAGE=ENU'
//SMPOUT�� DD� SYSOUT=*
//SMPRPT�� DD� SYSOUT=*
//SMPLIST� DD� SYSOUT=*
//SYSPRINT DD� SYSOUT=*
//SMPLOG�� DD� DUMMY
//SMPPTFIN DD� DSN=SMPMCS,DISP=(SHR,PASS),UNIT=CART,LABEL=(5,SL),
//������������ VOL=SER=(Z10433,Z10434,Z10435,Z10436,Z10437,Z10438)
//SMPHOLD� DD� DUMMY
//SMPCNTL� DD� *
����� SET� BOUNDARY (GLOBAL).
� RECEIVE� SOURCEID (PDO9739)� SYSMODS
���������� SELECT (JTCP32C,JTCP32H).
/*


Here's a new one on SMP4:
//REPORT� EXEC PGM=GIMSMP,PARM='CSI=DBS.GLOBAL.CSI,LANGUAGE=ENU'
//SMPOUT�� DD� SYSOUT=*
//SMPRPT�� DD� SYSOUT=*
//SYSPRINT DD� SYSOUT=*
//SMPLIST� DD� SYSOUT=*
//SMPLOG�� DD� DUMMY
//SMPCNTL� DD� *
����� SET� BOUNDARY (GLOBAL).
�� REPORT� SYSMODS� INZONE (DBSTZN)� COMPAREDTO (DBSPZN)� NOPUNCH.
/*

I keep old statements after the null card to reduce syntax research:
//RESTORE EXEC PGM=GIMSMP,
//������������ PARM='CSI=MVSSMPE.GLOBAL.CSI,LANGUAGE=ENU'
//SMPOUT�� DD� SYSOUT=*
//SMPRPT�� DD� SYSOUT=*
//SYSPRINT DD� SYSOUT=*
//SMPLIST� DD� SYSOUT=*
//SMPLOG�� DD� DUMMY
//SMPCNTL� DD� *
����� SET� BOUNDARY (FTP1B).
� RESTORE� SELECT (TCPMOD1).
/*
//
� RESTORE� SELECT (NCL1349)� GROUP� CHECK.
� RESTORE� SELECT (CO75692,GO12830,GO12833,GO12834,GO12837,GO12853)
���������� CHECK.
//CKS10LLD DD� DSN=CAID.CKS10LLD,DISP=SHR
//CKR10LLD DD� DSN=CAID.CKR10LLD,DISP=SHR
� RESTORE� SELECT (GFC0002,GFC0003,GFC0009,GFC0010,GFC0017,SRBFLGS)
���������� BYPASS (ID)� GROUP� CHECK.
//CZ260MLD DD� DSN=CAID.CZ260MLD,DISP=SHR
//CZ260LLD DD� DSN=CAID.CZ260LLD,DISP=SHR
����� SET� BOUNDARY (CAIPZN).
� RESTORE� SELECT (T5VQ141)� BYPASS (ID)� GROUP� CHECK.

SYSGEN?� No, thank you.� I have SMP/E:
//GENERATE EXEC PGM=GIMSMP,PARM='CSI=MVSSMPE.GLOBAL.CSI,LANGUAGE=ENU'
//SMPOUT�� DD� SYSOUT=*
//SMPRPT�� DD� SYSOUT=*
//SMPLIST� DD� SYSOUT=*
//SYSPRINT DD� SYSOUT=*
//SMPLOG�� DD� DUMMY
//SMPPUNCH DD� DSN=T$QGP75.SMPPUNCH.DATA,DISP=SHR
//JOBCARD� DD� DSN=T$QGP75.JOBS.CNTL(JOBCARD),DISP=SHR
//SMPCNTL� DD� *
����� SET� BOUNDARY (FTP1B).
�GENERATE� JOBCARD (JOBCARD)
���������� FORFMID (CF33000,CS91000,
���������� CW11000,CW11001,CW21000,CW31000,CW41000,CW51000).
/*
//
�GENERATE� JOBCARD (JOBCARD)� FORFMID (HSP3602)� REPLACE.

Here's an APPLY statement for DB2 V2R3 from 1997:
APPLY� SELECT (HDB2230,HIX2230,HIY2230,HIZ2230)� PTFS
������ COMPRESS (ALL)� EXSRCID (SMCOR)� CHECK� BYPASS (HOLDSYS).

Do you take rejection well?� Here are some sample statements:
SET� BOUNDARY (GLOBAL).
REJECT� PURGE (FTPDLB)� HOLDDATA.
REJECT� NOFMID� HOLDDATA.
REJECT� SELECT (JDV3270,JDV3275,JDV3276).
REJECT� FORFMID (JDV3270,JDV3275,JDV3276).

Enough, already, but Peppe did ask...
:)

Cheers,
Greg



------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
Giuseppe Vitillaro giuseppe@vitillaro.org [H390-MVS]
2018-09-05 09:42:52 UTC
Permalink
Post by pricgren ***@yahoo.com [H390-MVS]
Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
I wonder how this mess is managed in a modern Z/OS.
Enough, already, but Peppe did ask...
:)
Yep, Greg, I asked and I appreciated the answers.

Thanks to all.

I always appreciate 'details', I love 'details'.

The devil is always in the 'details', isn't it? ;-)

By the way, the answers I got over time in the hercules
groups, pile up over time, in my logs and in my mind.

They are not lost ;-) And ... as long as the Net is
"alive" ... they will never get lost.

Peppe.
Mike Stramba mikestramba@gmail.com [H390-MVS]
2018-09-05 10:40:46 UTC
Permalink
On 9/5/18, pricgren ***@yahoo.com [H390-MVS]
<H390-***@yahoogroups.com> wrote:
=> And now, some exhibits from the museum... (bail out now if you don't
Post by pricgren ***@yahoo.com [H390-MVS]
like JCL - or SMP)
//RECEIVE EXEC PGM=GIMSMP,
//ᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵ
//SMPLISTᅵ DDᅵ SYSOUT=*
//SYSPRINT DDᅵ SYSOUT=*
//SMPLOGᅵᅵ DDᅵ DUMMY
//SMPPTFIN DDᅵ DSN=SMPMCS,DISP=(SHR,PASS),UNIT=CART,LABEL=(5,SL),
//ᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵ
VOL=SER=(Z10433,Z10434,Z10435,Z10436,Z10437,Z10438)
//SMPHOLDᅵ DDᅵ DUMMY
//SMPCNTLᅵ DDᅵ *
ᅵᅵᅵᅵᅵ SETᅵ BOUNDARY (GLOBAL).
ᅵ RECEIVEᅵ SOURCEID (PDO9739)ᅵ SYSMODS
ᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵ SELECT (JTCP32C,JTCP32H).
Greg, however you cut / pasted the JCL, it looks like "apl" ... or
'sumpthin ? ;)
Post by pricgren ***@yahoo.com [H390-MVS]
//ᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵ
Mike
'au1john' au1john@yahoo.com.au [H390-MVS]
2018-09-05 11:18:10 UTC
Permalink
Try this.. if it gets mangled, copy and paste to something that has a fixed font e.g Windows Notepad which I used to clean it up) .

John



And now, some exhibits from the museum... (bail out now if you don't
like JCL - or SMP)

JCL from the 90s I found, back when TCPIP was not part of MVS/ESA V4:
//RECEIVE EXEC PGM=GIMSMP,
// PARM='CSI=MVSSMPE.GLOBAL.CSI,LANGUAGE=ENU'
//SMPOUT DD SYSOUT=*
//SMPRPT DD SYSOUT=*
//SMPLIST DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SMPLOG DD DUMMY
//SMPPTFIN DD DSN=SMPMCS,DISP=(SHR,PASS),UNIT=CART,LABEL=(5,SL),
// VOL=SER=(Z10433,Z10434,Z10435,Z10436,Z10437,Z10438)
//SMPHOLD DD DUMMY
//SMPCNTL DD *
SET BOUNDARY (GLOBAL).
RECEIVE SOURCEID (PDO9739) SYSMODS
SELECT (JTCP32C,JTCP32H).
/*


Here's a new one on SMP4:
//REPORT EXEC PGM=GIMSMP,PARM='CSI=DBS.GLOBAL.CSI,LANGUAGE=ENU'
//SMPOUT DD SYSOUT=*
//SMPRPT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SMPLIST DD SYSOUT=*
//SMPLOG DD DUMMY
//SMPCNTL DD *
SET BOUNDARY (GLOBAL).
REPORT SYSMODS INZONE (DBSTZN) COMPAREDTO (DBSPZN) NOPUNCH.
/*

I keep old statements after the null card to reduce syntax research:
//RESTORE EXEC PGM=GIMSMP,
// PARM='CSI=MVSSMPE.GLOBAL.CSI,LANGUAGE=ENU'
//SMPOUT DD SYSOUT=*
//SMPRPT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SMPLIST DD SYSOUT=*
//SMPLOG DD DUMMY
//SMPCNTL DD *
SET BOUNDARY (FTP1B).
RESTORE SELECT (TCPMOD1).
/*
//
RESTORE SELECT (NCL1349) GROUP CHECK.
RESTORE SELECT (CO75692,GO12830,GO12833,GO12834,GO12837,GO12853)
CHECK.
//CKS10LLD DD DSN=CAID.CKS10LLD,DISP=SHR
//CKR10LLD DD DSN=CAID.CKR10LLD,DISP=SHR
RESTORE SELECT (GFC0002,GFC0003,GFC0009,GFC0010,GFC0017,SRBFLGS)
BYPASS (ID) GROUP CHECK.
//CZ260MLD DD DSN=CAID.CZ260MLD,DISP=SHR
//CZ260LLD DD DSN=CAID.CZ260LLD,DISP=SHR
SET BOUNDARY (CAIPZN).
RESTORE SELECT (T5VQ141) BYPASS (ID) GROUP CHECK.

SYSGEN? No, thank you. I have SMP/E:
//GENERATE EXEC PGM=GIMSMP,PARM='CSI=MVSSMPE.GLOBAL.CSI,LANGUAGE=ENU'
//SMPOUT DD SYSOUT=*
//SMPRPT DD SYSOUT=*
//SMPLIST DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SMPLOG DD DUMMY
//SMPPUNCH DD DSN=T$QGP75.SMPPUNCH.DATA,DISP=SHR
//JOBCARD DD DSN=T$QGP75.JOBS.CNTL(JOBCARD),DISP=SHR
//SMPCNTL DD *
SET BOUNDARY (FTP1B).
GENERATE JOBCARD (JOBCARD)
FORFMID (CF33000,CS91000,
CW11000,CW11001,CW21000,CW31000,CW41000,CW51000).
/*
//
GENERATE JOBCARD (JOBCARD) FORFMID (HSP3602) REPLACE.

Here's an APPLY statement for DB2 V2R3 from 1997:
APPLY SELECT (HDB2230,HIX2230,HIY2230,HIZ2230) PTFS
COMPRESS (ALL) EXSRCID (SMCOR) CHECK BYPASS (HOLDSYS).

Do you take rejection well? Here are some sample statements:
SET BOUNDARY (GLOBAL).
REJECT PURGE (FTPDLB) HOLDDATA.
REJECT NOFMID HOLDDATA.
REJECT SELECT (JDV3270,JDV3275,JDV3276).
REJECT FORFMID (JDV3270,JDV3275,JDV3276).

-----Original Message-----
From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Wednesday, 5 September 2018 20:41
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Enable "ST *" for REVOUT?

On 9/5/18, pricgren ***@yahoo.com [H390-MVS]
<H390-***@yahoogroups.com> wrote:
=> And now, some exhibits from the museum... (bail out now if you don't
Post by pricgren ***@yahoo.com [H390-MVS]
like JCL - or SMP)
//RECEIVE EXEC PGM=GIMSMP,
//ᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵ
//SMPLISTᅵ DDᅵ SYSOUT=*
//SYSPRINT DDᅵ SYSOUT=*
//SMPLOGᅵᅵ DDᅵ DUMMY
//SMPPTFIN DDᅵ DSN=SMPMCS,DISP=(SHR,PASS),UNIT=CART,LABEL=(5,SL),
//ᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵ
VOL=SER=(Z10433,Z10434,Z10435,Z10436,Z10437,Z10438)
//SMPHOLDᅵ DDᅵ DUMMY
//SMPCNTLᅵ DDᅵ *
ᅵᅵᅵᅵᅵ SETᅵ BOUNDARY (GLOBAL).
ᅵ RECEIVEᅵ SOURCEID (PDO9739)ᅵ SYSMODS
ᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵ SELECT (JTCP32C,JTCP32H).
Greg, however you cut / pasted the JCL, it looks like "apl" ... or
'sumpthin ? ;)
Post by pricgren ***@yahoo.com [H390-MVS]
//ᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵᅵ
Mike


------------------------------------
Posted by: Mike Stramba <***@gmail.com>
------------------------------------


------------------------------------

Yahoo Groups Links
pricgren pricgren@yahoo.com [H390-MVS]
2018-09-06 08:56:24 UTC
Permalink
Greg, however you cut / pasted the JCL, it looks like "apl" ... or
'sumpthin ? ;)
Yeah, I was very surprised when I saw that...
- I have no explanation.

I'm now glad I trimmed off the trailing blanks...
:/

At least John had a work-around.

Cheers,
Greg
Giuseppe Vitillaro giuseppe@vitillaro.org [H390-MVS]
2018-09-03 10:31:11 UTC
Permalink
Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
Hello again --
Almost have my custom-built MVS 3.8 system set up with the features from
TK4- I want (why not just use TK4-? To learn how to do things myself, of
course! Surely most folks on this list understand that motivation), but one
question remains...
When using REVOUT on TK4- (either from REVIEW's 3.8 option or starting
REVOUT from TSO), I have an option to use "ST *" to see the status of all
jobs.
On my system, I don't get the hint at the bottom of REVOUT to do that, and
ST * doesn't work.
My research has led me to usermod SLB0001 that provides user exit IKJEFF53.
Now from TSO my user is permitted to view arbitrary job names with STATUS
and OUTPUT. I assume that's part of the puzzle to enable REVIEW to show me
output from other jobs. And, indeed, if I know the specific job name I can
do "ST jobname" in REVOUT and view the held output.
But the "ST *" command still isn't working for me. (I also note that REVOUT
on TK4- has a couple extra columns, QUEUE and EXEC).
Are there other usermods I need to enable that functionality? Or something
else?
As always, thank you for your help!
-Matthew
From my notes, about my personal SYSGEN, modeled
over the TK3/TK4- SYSGEN, to have "ST *" (and the
FREE footnote message) working in REVOUT, the
UMOD SYS1.UMODCNTL(TJES801) (from TK4-) is definitely
a must.

Peppe.
Loading...