Serialization (was: Inquire intrdr default job class)

[Paul Gilmartin]

On Thu, 10 Dec 2015 15:29:24 -0500, Robert A. Rosenberg wrote:
>>
>>QNAME SPFEDIT is only used for PDS[E]. SYSDSN is another issue, but
>>there the volser is not known in time to include in the RNAME.
>
>I agree about SYSDSN being issued at times (JCL DISP for example)
>where the VOLSER may not yet be known so it can not be used as part
>of the RNAME. The fact that there are times when the VOLSER *IS*
>known does not help due to the unknown VOLSER cases. I think that
>this situation is one of the things that JES3 handles by not letting
>a JOB be submitted/run unless the DSN is not being referenced by any
>other job's JCL.
> 
But this becmes increasingly inappropriate with increasing use of
DYNALLOC by TSO/E, ISPF, FTP, NFS, etc.

It appears that NFS (and FTP?) use SPFEDIT-style PDS serialization.

I understand that PDSE supports concurrent writing to different
members of the same PDSE.  (What scope?  Same task?
Different address spaces?  Different LPARs?)  A while ago, I did a
crude experiment which appeared to show that ISPF is not savvy
to this capablity: LMINIT for Write two different members of the
same PDSE and perform interleaved LMPUTs to them.  Failed
somewhere along the way.  I might try this with NFS.  Would
ISPF-L be a better forum for this topic?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Shmuel Metz (Seymour J.)]

In <20151210035136.5fe8e33...@panix2.panix.com>, on 12/09/2015
   at 10:51 PM, Randy Hudson  said:

>MBBCCHHR.

That's a software format. The issue is the 2321 hardware format.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Robert A. Rosenberg]

At 23:28 -0500 on 12/09/2015, Shmuel Metz (Seymour J.) wrote about 
Re: Inquire intrdr default job class:



In <p06240402d28e2c3bf3c6@[192.168.1.241]>, on 12/09/2015
   at 02:22 PM, "Robert A. Rosenberg" <hal9...@panix.com> said:


You are focusing too much on the question of if the DSN is a
PDS//PDSE or some other format.


QNAME SPFEDIT is only used for PDS[E]. SYSDSN is another issue, but
there the volser is not known in time to include in the RNAME.


I agree about SYSDSN being issued at times (JCL DISP for example) 
where the VOLSER may not yet be known so it can not be used as part 
of the RNAME. The fact that there are times when the VOLSER *IS* 
known does not help due to the unknown VOLSER cases. I think that 
this situation is one of the things that JES3 handles by not letting 
a JOB be submitted/run unless the DSN is not being referenced by any 
other job's JCL.




--
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Shmuel Metz (Seymour J.)]

In , on 12/09/2015
   at 02:22 PM, "Robert A. Rosenberg"  said:

>You are focusing too much on the question of if the DSN is a 
>PDS//PDSE or some other format.

QNAME SPFEDIT is only used for PDS[E]. SYSDSN is another issue, but
there the volser is not known in time to include in the RNAME.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Creating multi volume PDS/E datasets (was Inquire Intrdr default job class)

[Lizette Koehler]

It seems this thread switched in the middle somewhere.  I am changing the 
subject so it is easier to see and find later.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Schwab
> Sent: Tuesday, December 08, 2015 10:15 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Inquire intrdr default job class
> 
> They were able to create it.  They were not able to open it.  IBM will fix 
> z/OS 2.2 so
> you CAN'T create a multi-volume PDS or PDSE.
> 
> On Tue, Dec 8, 2015 at 11:10 PM, Ed Gould <edgould1...@comcast.net> wrote:
> > Mike,
> >
> > Maybe I am reading too much into the APAR but if I read it correctly
> > then a SMS PDSE can be multivolume.
> > Does anyone else get the same reading?
> >
> > Ed
> >
> > On Dec 8, 2015, at 11:00 PM, Mike Schwab wrote:
> >
> >> On Tue, Dec 8, 2015 at 6:10 PM, Ed Gould <edgould1...@comcast.net> wrote:
> >>>
> >>>
> >>> This becomes a key point *IF* PDSE's ever become multi volume.
> >>> Somewhere in the recent past I *think* Ibm announced multi volume
> >>> pdse (I could be wrong but I do remember think about this when it
> >>> was announced).
> >>>
> >>> Ed
> >>
> >> A customer was able to do this.  Resulted in an APAR in 2014.
> >> http://www-01.ibm.com/support/docview.wss?uid=isg1OA45917
> >>
> >> --
> >> Mike A Schwab, Springfield IL USA
> >> Where do Forest Rangers go to get away from it all?
> >>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Creating multi volume PDS/E datasets (was Inquire Intrdr default job class)

[Tom Marchant]

On Wed, 9 Dec 2015 08:26:30 -0700, Lizette Koehler wrote:

>It seems this thread switched in the middle somewhere.  I am changing 
>the subject so it is easier to see and find later.

And that will help only if future replies are to your message. That's unlikely, 
especially since you didn't add anything in this message to the discussion.

Your point is well taken, though. It would be easier to follow discussions if 
people would change the subject when writing bout a different topic.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Shmuel Metz (Seymour J.)]

In <1428596541933945.wa.paulgboulderaim@listserv.ua.edu>, on
12/08/2015
   at 06:49 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>I think an obstacle is not having enough bits in the NOTE/POINT
>object to address so many blocks.

It's not that there aren't enough bits, but that so much existing code
depends on the current format.

>Look at the bizarre way CCHHR is dissected
>to allow more than 54 GB on a DASD volume.
 
Not much more bizzare than on the 2321. 

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[John McKown]

On Tue, Dec 8, 2015 at 6:37 PM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In
> ,
> on 12/08/2015
>at 03:21 PM, John McKown  said:
>
> > I do not really agree that not including the volser in the SYSDSN
> >enqueue is a "flaw". If it were done, then their could need to be
> >multiple ENQs, one for each volume in a multi-volume DSN.
>
> The ENQ is for a PDS member; a PDS can't be multivolume.
>
> >But remember this was designed in OS/360
>
> Which didn't allow a multi-volume PDS.
>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>


​OK, I've managed to confuse myself. You want the ENQ for SYSDSN to include
the volser if and only if the DSORG is a PDS, otherwise to omit it? That
is, if DSORG=PO then rname=dsn||volser else rname=dsn?
Again, think 360/30(?) running OS/360 MFT. That's more code in allocation,
which means less core for ​

​the user's program.

-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Shmuel Metz (Seymour J.)]

In

Re: Inquire intrdr default job class

[John McKown]

On Wed, Dec 9, 2015 at 12:29 PM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In
> 

Re: Inquire intrdr default job class

[Robert A. Rosenberg]

At 12:46 -0600 on 12/09/2015, John McKown wrote about Re: Inquire 
intrdr default job class:



On Wed, Dec 9, 2015 at 12:29 PM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:


 In
 

Re: JES2/3 Initialization member not reflecting current running system was Re: Inquire intrdr default job class

[Steve Horein]

I believe NewEra's Image Focus would reflect that in their audit reports.
I thought it was a really cool product when I was able to use it.

On Wed, Dec 9, 2015 at 5:23 PM, Jerry Whitteridge <
jerry.whitteri...@safeway.com> wrote:

> I'd also love to see that report, - most useful for both the subject under
> discussion but also to use as an integrity check that the system is
> configured as we expect.
>
> Jerry Whitteridge
> Manager Mainframe Systems & Storage
> Albertsons - Safeway Inc.
> 925 738 9443
> Corporate Tieline - 89443
>
> If you feel in control
> you just aren't going fast enough.
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of J O Skip Robinson
> Sent: Wednesday, December 09, 2015 3:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JES2/3 Initialization member not reflecting current running
> system was Re: Inquire intrdr default job class
>
> I would be more than happy with a report showing any inconsistencies
> between the running JES2 and the actual values coded in a user-selectable
> init deck. Let me decide how to resolve differences, when to do it, and by
> whom. As I said earlier, possibly fatal differences could hide for years
> until the next cold start.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> OR
> jo.skip.robin...@att.net
> OR
> jo.skip.robin...@gmail.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Clark Morris
> Sent: Tuesday, December 08, 2015 6:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):JES2/3 Initialization member not reflecting current
> running system was Re: Inquire intrdr default job class
>
> On 8 Dec 2015 14:27:38 -0800, in bit.listserv.ibm-main you wrote:
>
> >Professor Skip assumes that it will be done wrong--at least in execution.
> Unless the design anticipates and properly handles all execution flubs,
> then the design is wrong. What could go wrong?
> >
> >-- A faulty command is issued. If the update is echoed to the control
> file, the component (JES2 in this thread) might fail to come up or at least
> work properly at IPL time.
> >
> >-- A command is issued by an operator who may not even have READ access
> to JES2 parms, yet the content is written into the control file.
> >
> >-- Two or more commands are issued in quick succession--maybe by
> different people. What gets echoed to the control file?
> >
> >If you take a poll of sysprogs on whether to implement this mechanism, I
> doubt that many would be enthusiastic.
>
> As someone who did his last system programming with responsibility for JES
> over 25 years ago, I feel equally nervous about have a JES modified
> substantially from the initialization member settings by command where this
> situation persists over years.  There should be some mechanism to bring
> initialization deck in line with the current operation parameters.  One
> possibility would be a option in both JES2 and JES3 to create an
> initialization member from the settings in the current running system.
>
> Clark Morris
> >
> >.
> >.
> >.
> >J.O.Skip Robinson
> >Southern California Edison Company
> >Electric Dragon Team Paddler
> >SHARE MVS Program Co-Manager
> >626-302-7535 Office
> >323-715-0595 Mobile
> >jo.skip.robin...@sce.com
> >OR
> >jo.skip.robin...@att.net
> >OR
> >jo.skip.robin...@gmail.com
> >
> >-Original Message-
> >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >On Behalf Of Paul Gilmartin
> >Sent: Tuesday, December 08, 2015 9:29 AM
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Subject: (External):Re: Inquire intrdr default job class
> >
> >On 2015-12-08, at 10:05, J O Skip Robinson wrote:
> >
> >> When you're the only kid in the toy store, you have free reign. Even z
> HMC uses the 'write-back' function for tuning updates. But z/OS is a
> complex shared environment. You can't allow random process-altering
> commands to update common control data sets. Recipe for chaos.
> >>
> >A professor in a class I took once countered such an argument with:
> >
> >"Why do you assume it has to be done wrong!?"
> >
> >Straw man.  A wrong way would be for a sysadmin with a Windows-geek
> orientation to:
> >
> >o FTP a PARMLIB member to a desktop.
> >o Edit it with Notepad.
> >o FTP it ba

Re: JES2/3 Initialization member not reflecting current running system was Re: Inquire intrdr default job class

[Jerry Whitteridge]

I'd also love to see that report, - most useful for both the subject under 
discussion but also to use as an integrity check that the system is configured 
as we expect. 

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Wednesday, December 09, 2015 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2/3 Initialization member not reflecting current running system was 
Re: Inquire intrdr default job class

I would be more than happy with a report showing any inconsistencies between 
the running JES2 and the actual values coded in a user-selectable init deck. 
Let me decide how to resolve differences, when to do it, and by whom. As I said 
earlier, possibly fatal differences could hide for years until the next cold 
start.  

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
OR
jo.skip.robin...@att.net
OR
jo.skip.robin...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Tuesday, December 08, 2015 6:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):JES2/3 Initialization member not reflecting current running 
system was Re: Inquire intrdr default job class

On 8 Dec 2015 14:27:38 -0800, in bit.listserv.ibm-main you wrote:

>Professor Skip assumes that it will be done wrong--at least in execution. 
>Unless the design anticipates and properly handles all execution flubs, then 
>the design is wrong. What could go wrong? 
>
>-- A faulty command is issued. If the update is echoed to the control file, 
>the component (JES2 in this thread) might fail to come up or at least work 
>properly at IPL time.
>
>-- A command is issued by an operator who may not even have READ access to 
>JES2 parms, yet the content is written into the control file.
>
>-- Two or more commands are issued in quick succession--maybe by different 
>people. What gets echoed to the control file?
>
>If you take a poll of sysprogs on whether to implement this mechanism, I doubt 
>that many would be enthusiastic.  

As someone who did his last system programming with responsibility for JES over 
25 years ago, I feel equally nervous about have a JES modified substantially 
from the initialization member settings by command where this situation 
persists over years.  There should be some mechanism to bring initialization 
deck in line with the current operation parameters.  One possibility would be a 
option in both JES2 and JES3 to create an initialization member from the 
settings in the current running system.

Clark Morris
>
>.
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>626-302-7535 Office
>323-715-0595 Mobile
>jo.skip.robin...@sce.com
>OR
>jo.skip.robin...@att.net
>OR
>jo.skip.robin...@gmail.com
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Paul Gilmartin
>Sent: Tuesday, December 08, 2015 9:29 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Inquire intrdr default job class
>
>On 2015-12-08, at 10:05, J O Skip Robinson wrote:
>
>> When you're the only kid in the toy store, you have free reign. Even z HMC 
>> uses the 'write-back' function for tuning updates. But z/OS is a complex 
>> shared environment. You can't allow random process-altering commands to 
>> update common control data sets. Recipe for chaos. 
>>  
>A professor in a class I took once countered such an argument with:
>
>"Why do you assume it has to be done wrong!?"
>
>Straw man.  A wrong way would be for a sysadmin with a Windows-geek 
>orientation to:
>
>o FTP a PARMLIB member to a desktop.
>o Edit it with Notepad.
>o FTP it back.
>
>In fact, it's wrong only if two of them do it at once.
>
>ISPF EDIT has some effective techniques for serializing updates to PDS 
>members, precluding two programmers' editing the same member simultaneously.  
>Certainly an interactive tool with a "Save as Default" capability is less 
>chaotic than handwritten notes to operators, "When you IPL, be sure to issue 
>all the following SET commands ..."
>It seems to me that having a "... great many changes ... now made simply by 
>command ..." is equally a "[r]ecipe for chaos."  Only slightly less so if the 
>commands are embedded in a script automatically run at IPL.
>> 
>> 
>>

JES2/3 Initialization member not reflecting current running system was Re: Inquire intrdr default job class

[J O Skip Robinson]

I would be more than happy with a report showing any inconsistencies between 
the running JES2 and the actual values coded in a user-selectable init deck. 
Let me decide how to resolve differences, when to do it, and by whom. As I said 
earlier, possibly fatal differences could hide for years until the next cold 
start.  

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
OR
jo.skip.robin...@att.net
OR
jo.skip.robin...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Tuesday, December 08, 2015 6:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):JES2/3 Initialization member not reflecting current running 
system was Re: Inquire intrdr default job class

On 8 Dec 2015 14:27:38 -0800, in bit.listserv.ibm-main you wrote:

>Professor Skip assumes that it will be done wrong--at least in execution. 
>Unless the design anticipates and properly handles all execution flubs, then 
>the design is wrong. What could go wrong? 
>
>-- A faulty command is issued. If the update is echoed to the control file, 
>the component (JES2 in this thread) might fail to come up or at least work 
>properly at IPL time.
>
>-- A command is issued by an operator who may not even have READ access to 
>JES2 parms, yet the content is written into the control file.
>
>-- Two or more commands are issued in quick succession--maybe by different 
>people. What gets echoed to the control file?
>
>If you take a poll of sysprogs on whether to implement this mechanism, I doubt 
>that many would be enthusiastic.  

As someone who did his last system programming with responsibility for JES over 
25 years ago, I feel equally nervous about have a JES modified substantially 
from the initialization member settings by command where this situation 
persists over years.  There should be some mechanism to bring initialization 
deck in line with the current operation parameters.  One possibility would be a 
option in both JES2 and JES3 to create an initialization member from the 
settings in the current running system.

Clark Morris
>
>.
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>626-302-7535 Office
>323-715-0595 Mobile
>jo.skip.robin...@sce.com
>OR
>jo.skip.robin...@att.net
>OR
>jo.skip.robin...@gmail.com
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Paul Gilmartin
>Sent: Tuesday, December 08, 2015 9:29 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Inquire intrdr default job class
>
>On 2015-12-08, at 10:05, J O Skip Robinson wrote:
>
>> When you're the only kid in the toy store, you have free reign. Even z HMC 
>> uses the 'write-back' function for tuning updates. But z/OS is a complex 
>> shared environment. You can't allow random process-altering commands to 
>> update common control data sets. Recipe for chaos. 
>>  
>A professor in a class I took once countered such an argument with:
>
>"Why do you assume it has to be done wrong!?"
>
>Straw man.  A wrong way would be for a sysadmin with a Windows-geek 
>orientation to:
>
>o FTP a PARMLIB member to a desktop.
>o Edit it with Notepad.
>o FTP it back.
>
>In fact, it's wrong only if two of them do it at once.
>
>ISPF EDIT has some effective techniques for serializing updates to PDS 
>members, precluding two programmers' editing the same member simultaneously.  
>Certainly an interactive tool with a "Save as Default" capability is less 
>chaotic than handwritten notes to operators, "When you IPL, be sure to issue 
>all the following SET commands ..."
>It seems to me that having a "... great many changes ... now made simply by 
>command ..." is equally a "[r]ecipe for chaos."  Only slightly less so if the 
>commands are embedded in a script automatically run at IPL.
>> 
>> 
>> On 2015-12-07 09:58, J O Skip Robinson wrote:
>>> Gil's point raises an issue more critical than just the question at hand. 
>>> Once upon a time, 'reading JES2 parms' would have been a reasonable 
>>> strategy in general for determining how JES2 runs. Since the advent of 
>>> pervasive dynamic changes, however, the init deck as coded is no longer a 
>>> reliable window into JES2 processing. A great many changes are now made 
>>> simply by command. Old values are ignored on hot start and in many cases 
>>> even on all-system warm start. Only a cold start will reinstate coded parm 
>>> values t

Re: Inquire intrdr default job class

[Randy Hudson]

In article <p06240403d28e3033e1d1@[192.168.1.241]>,
  "Robert A. Rosenberg" <hal9...@panix.com> wrote:

> At 12:49 -0500 on 12/09/2015, Shmuel Metz (Seymour J.) wrote about 
>  Re: Inquire intrdr default job class:
>
>>> Look at the bizarre way CCHHR is dissected
>>> to allow more than 54 GB on a DASD volume.
>>
>> Not much more bizzare than on the 2321.
>
> The CCHHR for the 2321 was MCCHHR (where M selected the BIN). All 
> non-2321 CCHHRs had the M ignored or just set to 0.

MBBCCHHR.  BB was Bin number.  M is Extent number.  Yes, many programs took
shortcuts, assuming those would be zero, or irrelevant because they were
handled elsewhere.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Robert A. Rosenberg]

At 19:37 -0500 on 12/08/2015, Shmuel Metz (Seymour J.) wrote about 
Re: Inquire intrdr default job class:



In
<caajsdjgdcfhh4eonuruomvc7ovkk4wu8eado_yimw6fspnw...@mail.gmail.com>,
on 12/08/2015
   at 03:21 PM, John McKown <john.archie.mck...@gmail.com> said:


 I do not really agree that not including the volser in the SYSDSN
enqueue is a "flaw". If it were done, then their could need to be
multiple ENQs, one for each volume in a multi-volume DSN.


The ENQ is for a PDS member; a PDS can't be multivolume.


But remember this was designed in OS/360


Which didn't allow a multi-volume PDS.


You are focusing too much on the question of if the DSN is a 
PDS//PDSE or some other format. The flaw I was pointing out is that 
for ANY DSN that is not unique the SYSDSN ENQ invalidly assumes that 
the DSN sans VOLSER is enough to identify the dataset. Thus ANY 
attempt to open DSN1 on VOLSER1 can prevent access to DSN1 on VOLSER2 
due to the incorrect claim by ENQ that there is an ENQ on the VOLSER2 
DSN1. This situation existed all the way back to OS/360 as soon as 
you had more than 1 volume but has become much more of an issue due 
to cross system sharing of the ENQs. I have no solution to this issue 
but I am just pointing it out.


As I noted in a prior reply this assumption that DSN (as the RNAME) 
is enough to identify the dataset for the SPFEDIT ENQ is broken since 
the VOLSER is KNOWN at ENQ time and thus SHOULD be part of the RNAME 
so as to allow different datasets with the same name to be 
edited/accessed without the current inability to access them.




--
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Robert A. Rosenberg]

At 12:49 -0500 on 12/09/2015, Shmuel Metz (Seymour J.) wrote about 
Re: Inquire intrdr default job class:



 >Look at the bizarre way CCHHR is dissected

to allow more than 54 GB on a DASD volume.


Not much more bizzare than on the 2321.


The CCHHR for the 2321 was MCCHHR (where M selected the BIN). All 
non-2321 CCHHRs had the M ignored or just set to 0.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Shmuel Metz (Seymour J.)]

In
,
on 12/08/2015
   at 03:21 PM, John McKown  said:

> I do not really agree that not including the volser in the SYSDSN
>enqueue is a "flaw". If it were done, then their could need to be
>multiple ENQs, one for each volume in a multi-volume DSN.

The ENQ is for a PDS member; a PDS can't be multivolume.

>But remember this was designed in OS/360 

Which didn't allow a multi-volume PDS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: length of "executable" (I meant Re: Inquire intrdr default job class)

[Paul Gilmartin]

Ouch!  I hybridized two threads.  I meant to reply to "inquire intrdr"
but posted instead to "length of executable".

On Tue, 8 Dec 2015 00:44:57 -0600, Elardus Engelbrecht wrote:

>Shmuel Metz (Seymour J.) wrote:
>
>>>The first restriction I see is:
>>>The CONSOLE host command environment is available only to REXX execs 
>>> that run in the TSO/E address space.
>
>>And SDSF is available without TSO?
>
Absolutely.  RTFM.

>Yes, look at EXEC PGM=ISFAFD. [1]
>
Ugh!  Long ago WJS posted something like that to MVS-OE.  Lately the
Rexx API to SDSF is better.  And I posted an example in Rexx of issuing
an operator command and capturing the reply in the "executable" (should
have been "inquire") thread at:

https://listserv.ua.edu/cgi-bin/wa?A2=ind1512=ibm-main=R14428&1=ibm-main

>Groete / Greetings
>Elardus Engelbrecht
>
>[1] - You can get SDSF lookalike on other products (only if you are licensed 
>to that.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[J O Skip Robinson]

When you're the only kid in the toy store, you have free reign. Even z HMC uses 
the 'write-back' function for tuning updates. But z/OS is a complex shared 
environment. You can't allow random process-altering commands to update common 
control data sets. Recipe for chaos. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
OR
jo.skip.robin...@att.net
OR
jo.skip.robin...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, December 07, 2015 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Inquire intrdr default job class

On 2015-12-07 09:58, J O Skip Robinson wrote:
> Gil's point raises an issue more critical than just the question at hand. 
> Once upon a time, 'reading JES2 parms' would have been a reasonable strategy 
> in general for determining how JES2 runs. Since the advent of pervasive 
> dynamic changes, however, the init deck as coded is no longer a reliable 
> window into JES2 processing. A great many changes are now made simply by 
> command. Old values are ignored on hot start and in many cases even on 
> all-system warm start. Only a cold start will reinstate coded parm values 
> that might actually be years out of date.
> 
> There is today no substitute for a display command with full detail. 
> 
More modern systems, often on desktops, have similar dynamic change facilities. 
 However they often have a "Save as Default" checkbox which does the equivalent 
of writing the changes back to the init deck and making them persistent.

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On 2015-12-08, at 10:05, J O Skip Robinson wrote:

> When you're the only kid in the toy store, you have free reign. Even z HMC 
> uses the 'write-back' function for tuning updates. But z/OS is a complex 
> shared environment. You can't allow random process-altering commands to 
> update common control data sets. Recipe for chaos. 
>  
A professor in a class I took once countered such an argument with:

"Why do you assume it has to be done wrong!?"

Straw man.  A wrong way would be for a sysadmin with a Windows-geek
orientation to:

o FTP a PARMLIB member to a desktop.
o Edit it with Notepad.
o FTP it back.

In fact, it's wrong only if two of them do it at once.

ISPF EDIT has some effective techniques for serializing updates to
PDS members, precluding two programmers' editing the same member
simultaneously.  Certainly an interactive tool with a "Save as
Default" capability is less chaotic than handwritten notes to operators,
"When you IPL, be sure to issue all the following SET commands ..."
It seems to me that having a "... great many changes ... now made simply
by command ..." is equally a "[r]ecipe for chaos."  Only slightly less
so if the commands are embedded in a script automatically run at IPL.
> 
> 
> On 2015-12-07 09:58, J O Skip Robinson wrote:
>> Gil's point raises an issue more critical than just the question at hand. 
>> Once upon a time, 'reading JES2 parms' would have been a reasonable strategy 
>> in general for determining how JES2 runs. Since the advent of pervasive 
>> dynamic changes, however, the init deck as coded is no longer a reliable 
>> window into JES2 processing. A great many changes are now made simply by 
>> command. Old values are ignored on hot start and in many cases even on 
>> all-system warm start. Only a cold start will reinstate coded parm values 
>> that might actually be years out of date.
>> 
>> There is today no substitute for a display command with full detail. 
>> 
> More modern systems, often on desktops, have similar dynamic change 
> facilities.  However they often have a "Save as Default" checkbox which does 
> the equivalent of writing the changes back to the init deck and making them 
> persistent.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On Tue, 8 Dec 2015 14:30:25 -0500, Robert A. Rosenberg  wrote:

>At 10:29 -0700 on 12/08/2015, Paul Gilmartin wrote about Re: Inquire
>intrdr default job class:
>
>>ISPF EDIT has some effective techniques for serializing updates to
>>PDS members, precluding two programmers' editing the same member
>>simultaneously.
>
>Does the ISPF EDIT support take into account that the "Same Member"
>means the same PDS not just any PDS with the same name but different
>volumes? Using the PDS name without qualifying it with the VOLSER
>where it resides is the same problem/design-flaw which ENQ on SYSDSN
>has since it leads to False Positive errors claiming the resource is
>in use due to not bothering to take into account the volume where a
>dataset resides.
> 
I wonder whether IBM knows about that.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Robert A. Rosenberg]

At 10:29 -0700 on 12/08/2015, Paul Gilmartin wrote about Re: Inquire 
intrdr default job class:



ISPF EDIT has some effective techniques for serializing updates to
PDS members, precluding two programmers' editing the same member
simultaneously.


Does the ISPF EDIT support take into account that the "Same Member" 
means the same PDS not just any PDS with the same name but different 
volumes? Using the PDS name without qualifying it with the VOLSER 
where it resides is the same problem/design-flaw which ENQ on SYSDSN 
has since it leads to False Positive errors claiming the resource is 
in use due to not bothering to take into account the volume where a 
dataset resides.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Gabor Hoffer]

Klaus,

I think, that's what I'm looking for..   many thanks!

Gabor

On Tue, Dec 8, 2015 at 8:30 AM, Klaus Stanislawiak <
klaus.stanislaw...@softwareag.com> wrote:

> I suggest to take a look at JES device information services (SSI function
> code 83), described here:
>
> https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaf200/ssifc83.htm
> The corresponding macro IAZSSJD indicates that the SSI returns a "Reader
> common section" containing field JDRCDFJC (Default job class).
> HTH
> Regards,
> Klaus Stanislawiak
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On Tue, 8 Dec 2015 22:24:09 +, J O Skip Robinson wrote:

>Professor Skip assumes that it will be done wrong--at least in execution. 
>Unless the design anticipates and properly handles all execution flubs, then 
>the design is wrong. What could go wrong? 
>
The design should be made right.

>-- A faulty command is issued. If the update is echoed to the control file, 
>the component (JES2 in this thread) might fail to come up or at least work 
>properly at IPL time.
>
A faulty update is made to the control file, perhaps with the ISPF editor.  ...
I assume a well-managed system has controls to prevent this, perhaps
a validation filter.  The same filter should operate on "Save as Default".

>-- A command is issued by an operator who may not even have READ access to 
>JES2 parms, yet the content is written into the control file.
>
??? Doesn't RACF prevent updates, however indirectly, to a control file by an 
operator,
programmer, admiistrator, CIO, or CEO who hasn't WRITE access?

>-- Two or more commands are issued in quick succession--maybe by different 
>people. What gets echoed to the control file?
>
Two or more updates are made to the control file--maybe by different people 
using the
ISPF editor.  Which prevails?  I'll assume locking of sufficient scope that 
this is as impossible
as ISPF, for example, makes it.

I've coded for SQL/DS (System R on CMS) and in my coding I needed to deal with
situations in which two or more people made conflicting updates.  One must be
ROLLBACK and the other COMMITed.

>If you take a poll of sysprogs on whether to implement this mechanism, I doubt 
>that many would be enthusiastic.  
>
I admit I was somewhat in the blue sky.  But the present situation where much of
the configuration is by command rather than control file still strikes me as 
chaotic.
An operator can easily issue a command that makes the system inoperative.  The
recovery is IPL, however unpleasant.

How about tweaking the configuration by command, then after several hours (or
weeks) of validation snapshoting the configuration to control file(s)?

Don't PARMLIB members have some sort of two-digit numeric version suffix?  Can 
the
operator at IPL elect an earlier version?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Ed Gould]

--SNIP--

​The "flaw" exists:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ispzpc90/ 
APPENDIX1.1.3


APPENDIX1.1.3 Member name enqueue


To restrict concurrent use of a member of a partitioned data set,  
while
still allowing ISPF users to use different members of the same data  
set
(PDF EDIT, Table Processing, File Tailoring), ISPF issues this ENQ  
macro

for the member:

   ENQ SPFEDIT,rname,E,52,SYSTEMS

where

rname
​ ​
the data set name, length of 44, padded with blanks, followed by  
the member

name, length of 8, padded with blanks
​


​I do not really agree that not including the volser in the SYSDSN  
enqueue
is a "flaw". If it were done, then their could need to b​e  
multiple ENQs,
one for each volume in a multi-volume DSN. Also, when a DSN is  
extended to
another volume, then an new SYSDSN ENQ would need to be issued.  
This could
possibly fail, although I would think it unlikely. But remember  
this was
designed in OS/360 and "set in stone" back when it would cost much  
more,
relatively speaking, in CPU and main memory overhead. Once "set in  
stone",
changing it is very difficult. Not only to code & test, but to put  
up with
customers who could start screaming about needing to change their  
code to

be compatible.



-- ---SNIP---


This becomes a key point *IF* PDSE's ever become multi volume.  
Somewhere in the recent past I *think* Ibm announced multi volume  
pdse (I could be wrong but I do remember think about this when it was  
announced).


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Tony Harminc]

On Dec 7, 2015 12:47 PM, "Paul Gilmartin" <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Mon, 7 Dec 2015 12:35:47 -0500, Shmuel Metz (Seymour J.) wrote:
>
> > on 12/07/2015 at 08:57 AM, Paul Gilmartin said:
> >
> >>(Is MGR now specified to support other than START or REPLY?)
> >
> >MGCR has always supported other than START or REPLY.
> >
> No:
>
https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa300/mgcr.htm
> ...
> Restrictions
> You can use MGCR to issue only START or REPLY commands. You must use
MGCRE for any other commands.
>
> I can hardly imagine a more explicit statement of a restriction.  MGCRE
is the alternative.

Surely the question is when IBM added and documented the documented
restriction. MGCR has in practice supported other commands roughly forever,
and certainly for much longer than MGCRE has existed.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[J O Skip Robinson]

Professor Skip assumes that it will be done wrong--at least in execution. 
Unless the design anticipates and properly handles all execution flubs, then 
the design is wrong. What could go wrong? 

-- A faulty command is issued. If the update is echoed to the control file, the 
component (JES2 in this thread) might fail to come up or at least work properly 
at IPL time.

-- A command is issued by an operator who may not even have READ access to JES2 
parms, yet the content is written into the control file.

-- Two or more commands are issued in quick succession--maybe by different 
people. What gets echoed to the control file?

If you take a poll of sysprogs on whether to implement this mechanism, I doubt 
that many would be enthusiastic.  

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
OR
jo.skip.robin...@att.net
OR
jo.skip.robin...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 08, 2015 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Inquire intrdr default job class

On 2015-12-08, at 10:05, J O Skip Robinson wrote:

> When you're the only kid in the toy store, you have free reign. Even z HMC 
> uses the 'write-back' function for tuning updates. But z/OS is a complex 
> shared environment. You can't allow random process-altering commands to 
> update common control data sets. Recipe for chaos. 
>  
A professor in a class I took once countered such an argument with:

"Why do you assume it has to be done wrong!?"

Straw man.  A wrong way would be for a sysadmin with a Windows-geek orientation 
to:

o FTP a PARMLIB member to a desktop.
o Edit it with Notepad.
o FTP it back.

In fact, it's wrong only if two of them do it at once.

ISPF EDIT has some effective techniques for serializing updates to PDS members, 
precluding two programmers' editing the same member simultaneously.  Certainly 
an interactive tool with a "Save as Default" capability is less chaotic than 
handwritten notes to operators, "When you IPL, be sure to issue all the 
following SET commands ..."
It seems to me that having a "... great many changes ... now made simply by 
command ..." is equally a "[r]ecipe for chaos."  Only slightly less so if the 
commands are embedded in a script automatically run at IPL.
> 
> 
> On 2015-12-07 09:58, J O Skip Robinson wrote:
>> Gil's point raises an issue more critical than just the question at hand. 
>> Once upon a time, 'reading JES2 parms' would have been a reasonable strategy 
>> in general for determining how JES2 runs. Since the advent of pervasive 
>> dynamic changes, however, the init deck as coded is no longer a reliable 
>> window into JES2 processing. A great many changes are now made simply by 
>> command. Old values are ignored on hot start and in many cases even on 
>> all-system warm start. Only a cold start will reinstate coded parm values 
>> that might actually be years out of date.
>> 
>> There is today no substitute for a display command with full detail. 
>> 
> More modern systems, often on desktops, have similar dynamic change 
> facilities.  However they often have a "Save as Default" checkbox which does 
> the equivalent of writing the changes back to the init deck and making them 
> persistent.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On Tue, 8 Dec 2015 18:10:44 -0600, Ed Gould wrote:
>
>This becomes a key point *IF* PDSE's ever become multi volume.  
>Somewhere in the recent past I *think* Ibm announced multi volume  
>pdse (I could be wrong but I do remember think about this when it was  
>announced).
> 
I think an obstacle is not having enough bits in the NOTE/POINT object to
address so many blocks.  Look at the bizarre way CCHHR is dissected
to allow more than 54 GB on a DASD volume.

Gordon Bell has famously harangued on the folly of skimping on
address bits.

https://what-if.xkcd.com/imgs/a/63/google_160kb.png

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Mike Schwab]

On Tue, Dec 8, 2015 at 6:10 PM, Ed Gould  wrote:
>
> This becomes a key point *IF* PDSE's ever become multi volume. Somewhere in
> the recent past I *think* Ibm announced multi volume pdse (I could be wrong
> but I do remember think about this when it was announced).
>
> Ed
A customer was able to do this.  Resulted in an APAR in 2014.
http://www-01.ibm.com/support/docview.wss?uid=isg1OA45917

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Mike Schwab]

They were able to create it.  They were not able to open it.  IBM will
fix z/OS 2.2 so you CAN'T create a multi-volume PDS or PDSE.

On Tue, Dec 8, 2015 at 11:10 PM, Ed Gould  wrote:
> Mike,
>
> Maybe I am reading too much into the APAR but if I read it correctly then a
> SMS PDSE can be multivolume.
> Does anyone else get the same reading?
>
> Ed
>
> On Dec 8, 2015, at 11:00 PM, Mike Schwab wrote:
>
>> On Tue, Dec 8, 2015 at 6:10 PM, Ed Gould  wrote:
>>>
>>>
>>> This becomes a key point *IF* PDSE's ever become multi volume. Somewhere
>>> in
>>> the recent past I *think* Ibm announced multi volume pdse (I could be
>>> wrong
>>> but I do remember think about this when it was announced).
>>>
>>> Ed
>>
>> A customer was able to do this.  Resulted in an APAR in 2014.
>> http://www-01.ibm.com/support/docview.wss?uid=isg1OA45917
>>
>> --
>> Mike A Schwab, Springfield IL USA
>> Where do Forest Rangers go to get away from it all?
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

JES2/3 Initialization member not reflecting current running system was Re: Inquire intrdr default job class

[Clark Morris]

On 8 Dec 2015 14:27:38 -0800, in bit.listserv.ibm-main you wrote:

>Professor Skip assumes that it will be done wrong--at least in execution. 
>Unless the design anticipates and properly handles all execution flubs, then 
>the design is wrong. What could go wrong? 
>
>-- A faulty command is issued. If the update is echoed to the control file, 
>the component (JES2 in this thread) might fail to come up or at least work 
>properly at IPL time.
>
>-- A command is issued by an operator who may not even have READ access to 
>JES2 parms, yet the content is written into the control file.
>
>-- Two or more commands are issued in quick succession--maybe by different 
>people. What gets echoed to the control file?
>
>If you take a poll of sysprogs on whether to implement this mechanism, I doubt 
>that many would be enthusiastic.  

As someone who did his last system programming with responsibility for
JES over 25 years ago, I feel equally nervous about have a JES
modified substantially from the initialization member settings by
command where this situation persists over years.  There should be
some mechanism to bring initialization deck in line with the current
operation parameters.  One possibility would be a option in both JES2
and JES3 to create an initialization member from the settings in the
current running system.

Clark Morris
>
>.
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler 
>SHARE MVS Program Co-Manager
>626-302-7535 Office
>323-715-0595 Mobile
>jo.skip.robin...@sce.com
>OR
>jo.skip.robin...@att.net
>OR
>jo.skip.robin...@gmail.com
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Paul Gilmartin
>Sent: Tuesday, December 08, 2015 9:29 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Inquire intrdr default job class
>
>On 2015-12-08, at 10:05, J O Skip Robinson wrote:
>
>> When you're the only kid in the toy store, you have free reign. Even z HMC 
>> uses the 'write-back' function for tuning updates. But z/OS is a complex 
>> shared environment. You can't allow random process-altering commands to 
>> update common control data sets. Recipe for chaos. 
>>  
>A professor in a class I took once countered such an argument with:
>
>"Why do you assume it has to be done wrong!?"
>
>Straw man.  A wrong way would be for a sysadmin with a Windows-geek 
>orientation to:
>
>o FTP a PARMLIB member to a desktop.
>o Edit it with Notepad.
>o FTP it back.
>
>In fact, it's wrong only if two of them do it at once.
>
>ISPF EDIT has some effective techniques for serializing updates to PDS 
>members, precluding two programmers' editing the same member simultaneously.  
>Certainly an interactive tool with a "Save as Default" capability is less 
>chaotic than handwritten notes to operators, "When you IPL, be sure to issue 
>all the following SET commands ..."
>It seems to me that having a "... great many changes ... now made simply by 
>command ..." is equally a "[r]ecipe for chaos."  Only slightly less so if the 
>commands are embedded in a script automatically run at IPL.
>> 
>> 
>> On 2015-12-07 09:58, J O Skip Robinson wrote:
>>> Gil's point raises an issue more critical than just the question at hand. 
>>> Once upon a time, 'reading JES2 parms' would have been a reasonable 
>>> strategy in general for determining how JES2 runs. Since the advent of 
>>> pervasive dynamic changes, however, the init deck as coded is no longer a 
>>> reliable window into JES2 processing. A great many changes are now made 
>>> simply by command. Old values are ignored on hot start and in many cases 
>>> even on all-system warm start. Only a cold start will reinstate coded parm 
>>> values that might actually be years out of date.
>>> 
>>> There is today no substitute for a display command with full detail. 
>>> 
>> More modern systems, often on desktops, have similar dynamic change 
>> facilities.  However they often have a "Save as Default" checkbox which does 
>> the equivalent of writing the changes back to the init deck and making them 
>> persistent.
>
>-- gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Robert A. Rosenberg]

At 15:21 -0600 on 12/08/2015, John McKown wrote about Re: Inquire 
intrdr default job class:



On Tue, Dec 8, 2015 at 3:05 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:


 On Tue, 8 Dec 2015 14:30:25 -0500, Robert A. Rosenberg  wrote:

 >At 10:29 -0700 on 12/08/2015, Paul Gilmartin wrote about Re: Inquire
 >intrdr default job class:
 >
 >>ISPF EDIT has some effective techniques for serializing updates to
 >>PDS members, precluding two programmers' editing the same member
 >>simultaneously.
 >
 >Does the ISPF EDIT support take into account that the "Same Member"
 >means the same PDS not just any PDS with the same name but different
 >volumes? Using the PDS name without qualifying it with the VOLSER
 >where it resides is the same problem/design-flaw which ENQ on SYSDSN
 >has since it leads to False Positive errors claiming the resource is
 >in use due to not bothering to take into account the volume where a
 >dataset resides.
 >
 I wonder whether IBM knows about that.


 > -- gil

ÐThe "flaw" exists:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ispzpc90/APPENDIX1.1.3

APPENDIX1.1.3 Member name enqueue

To restrict concurrent use of a member of a partitioned data set, while
still allowing ISPF users to use different members of the same data set
(PDF EDIT, Table Processing, File Tailoring), ISPF issues this ENQ macro
for the member:

   ENQ SPFEDIT,rname,E,52,SYSTEMS

where

rname
Ð Ð
the data set name, length of 44, padded with blanks, followed by the member
name, length of 8, padded with blanks
Ð


IMO a BIG DESIGN FLAW. At the time the ENQ SPFEDIT is issued SPF 
KNOWS the VOLSER of the PDS being edited and the failure/refusal to 
supply it as part of the RNAME leads to False Positives on "Already 
ENQ'ed" returns. If user1 is editing DSN(Member1) on VOLSER1 and 
user2 is editing DSN(Member1) on VOLSER2, whoever starts second is 
going to get an ENQ reject due to the ENQ ignoring the difference 
between the 2 DSN's VOLSERs.



ÐI do not really agree that not including the volser in the SYSDSN enqueue
is a "flaw". If it were done, then their could need to bÐe multiple ENQs,
one for each volume in a multi-volume DSN. Also, when a DSN is extended to
another volume, then an new SYSDSN ENQ would need to be issued. This could
possibly fail, although I would think it unlikely. But remember this was
designed in OS/360 and "set in stone" back when it would cost much more,
relatively speaking, in CPU and main memory overhead. Once "set in stone",
changing it is very difficult. Not only to code & test, but to put up with
customers who could start screaming about needing to change their code to
be compatible.



I call it a flaw but acknowledge that there is little that can be 
done to fix it. The ENQs that are issued at JCL time are issued in 
many cases before the VOLSER of the data sets is known. Thus you have 
to live with the fact that DSNs are not unique and have jobs single 
thread when datasets on different Volumes are referenced in the JCL


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Ed Gould]

Mike,

Maybe I am reading too much into the APAR but if I read it correctly  
then a SMS PDSE can be multivolume.

Does anyone else get the same reading?

Ed

On Dec 8, 2015, at 11:00 PM, Mike Schwab wrote:

On Tue, Dec 8, 2015 at 6:10 PM, Ed Gould   
wrote:


This becomes a key point *IF* PDSE's ever become multi volume.  
Somewhere in
the recent past I *think* Ibm announced multi volume pdse (I could  
be wrong

but I do remember think about this when it was announced).

Ed

A customer was able to do this.  Resulted in an APAR in 2014.
http://www-01.ibm.com/support/docview.wss?uid=isg1OA45917

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[John McKown]

On Tue, Dec 8, 2015 at 3:05 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 8 Dec 2015 14:30:25 -0500, Robert A. Rosenberg  wrote:
>
> >At 10:29 -0700 on 12/08/2015, Paul Gilmartin wrote about Re: Inquire
> >intrdr default job class:
> >
> >>ISPF EDIT has some effective techniques for serializing updates to
> >>PDS members, precluding two programmers' editing the same member
> >>simultaneously.
> >
> >Does the ISPF EDIT support take into account that the "Same Member"
> >means the same PDS not just any PDS with the same name but different
> >volumes? Using the PDS name without qualifying it with the VOLSER
> >where it resides is the same problem/design-flaw which ENQ on SYSDSN
> >has since it leads to False Positive errors claiming the resource is
> >in use due to not bothering to take into account the volume where a
> >dataset resides.
> >
> I wonder whether IBM knows about that.
>
> -- gil
>
>
>
​The "flaw" exists:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ispzpc90/APPENDIX1.1.3

APPENDIX1.1.3 Member name enqueue


To restrict concurrent use of a member of a partitioned data set, while
still allowing ISPF users to use different members of the same data set
(PDF EDIT, Table Processing, File Tailoring), ISPF issues this ENQ macro
for the member:

   ENQ SPFEDIT,rname,E,52,SYSTEMS

where

rname
​ ​
the data set name, length of 44, padded with blanks, followed by the member
name, length of 8, padded with blanks
​


​I do not really agree that not including the volser in the SYSDSN enqueue
is a "flaw". If it were done, then their could need to b​e multiple ENQs,
one for each volume in a multi-volume DSN. Also, when a DSN is extended to
another volume, then an new SYSDSN ENQ would need to be issued. This could
possibly fail, although I would think it unlikely. But remember this was
designed in OS/360 and "set in stone" back when it would cost much more,
relatively speaking, in CPU and main memory overhead. Once "set in stone",
changing it is very difficult. Not only to code & test, but to put up with
customers who could start screaming about needing to change their code to
be compatible.



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Klaus Stanislawiak]

I suggest to take a look at JES device information services (SSI function code 
83), described here:
https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaf200/ssifc83.htm
The corresponding macro IAZSSJD indicates that the SSI returns a "Reader common 
section" containing field JDRCDFJC (Default job class).
HTH
Regards,
Klaus Stanislawiak

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Ed Gould]

I think that is what I did 30 years ago.
I was trying to find the jobclass and it was not straight forward on  
how to do it and I think  (if memory serves me) that the trick was  
getting to the JES control blocks after that it was simple.


Ed

On Dec 7, 2015, at 8:54 PM, Anthony Thompson wrote:

No, it's a JES2 thing. And therefore you will find the mapping  
DSECT for $IRIS in SHASMAC.


I think you can chase it down from the CVT by going through  
CVTJESCT to find the first SSCT (primary JES2) -> SSCTSUS2 -> HCCT  
(which is a sort of CVT for JES2, mapped by $HCCT)


Otherwise you can get to the SSCT for JES2 by going through the SSVT.


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@listserv.ua.edu] On Behalf Of Paul Gilmartin

Sent: Tuesday, 8 December 2015 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inquire intrdr default job class

On Mon, 7 Dec 2015 18:40:56 -0600, Steve Horein  wrote:


Found this in JES2 Data Areas Volume 1:

Chapter 106. $IRIS Information
$IRIS Programming Interface Information $IRIS is a programming
interface.
$IRIS Heading Information
Common Name: IRIS
Macro ID: $IRIS
DSECT Name: IRIS


This looks like an IPCS thing.

o Is it usable outside IPCS, perhaps by chasing pointers from CVT?

o What MACLIB does it live in?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,  
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Inquire intrdr default job class

[Gabor Hoffer]

How can I inquire the internal reader characteristics from program (asm, c)?

$HASP838 INTRDR
$HASP838 INTRDR  AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),BATCH=YES,
$HASP838 CLASS=X,HOLD=NO,HONORLIM=NO,PRTYINC=0,
$HASP838 PRTYLIM=15,SYSAFF=(ANY),TRACE=NO

Actually, I'm interested in default job class.
Thanks in advance.

Gabor

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Lucas Rosalen]

Looks like $DINTRDR would suffice or $DINTRDR,C. Check this out:
https://www-01.ibm.com/support/knowledgecenter/mobile/#!/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasa200/dintrdr.htm

Lucas
On Dec 7, 2015 15:33, "Gabor Hoffer"  wrote:

> How can I inquire the internal reader characteristics from program (asm,
> c)?
>
> $HASP838 INTRDR
> $HASP838 INTRDR  AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),BATCH=YES,
> $HASP838 CLASS=X,HOLD=NO,HONORLIM=NO,PRTYINC=0,
> $HASP838 PRTYLIM=15,SYSAFF=(ANY),TRACE=NO
>
> Actually, I'm interested in default job class.
> Thanks in advance.
>
> Gabor
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On Mon, 7 Dec 2015 15:45:46 +0100, Lucas Rosalen wrote:

>Looks like $DINTRDR would suffice or $DINTRDR,C. Check this out:
>https://www-01.ibm.com/support/knowledgecenter/mobile/#!/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasa200/dintrdr.htm
> 
How do you code that in ASM or C (OP's question).  I suppose MGCR in ASM
(Is MGR now specified to support other than START or REPLY?)  How do
you capture the output?


>On Dec 7, 2015 15:33, "Gabor Hoffer" wrote:
>
>> How can I inquire the internal reader characteristics from program (asm,
>> c)?
>>
>> $HASP838 INTRDR
>> $HASP838 INTRDR  AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),BATCH=YES,
>> $HASP838 CLASS=X,HOLD=NO,HONORLIM=NO,PRTYINC=0,
>> $HASP838 PRTYLIM=15,SYSAFF=(ANY),TRACE=NO
>>
>> Actually, I'm interested in default job class.
>> Thanks in advance.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Gabor Hoffer]

Default jobclass of INTRDR, so before submit.

On Mon, Dec 7, 2015 at 4:09 PM, Vernooij, CP (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> Are you interested in the default jobclass of the INTRDR or in the
> jobclass your job will get if you don't specify one? Exits can modify the
> jobclass during/after submission.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gabor Hoffer
> Sent: 07 December, 2015 15:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Inquire intrdr default job class
>
> How can I inquire the internal reader characteristics from program (asm,
> c)?
>
> $HASP838 INTRDR
> $HASP838 INTRDR  AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),BATCH=YES,
> $HASP838 CLASS=X,HOLD=NO,HONORLIM=NO,PRTYINC=0,
> $HASP838 PRTYLIM=15,SYSAFF=(ANY),TRACE=NO
>
> Actually, I'm interested in default job class.
> Thanks in advance.
>
> Gabor
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Vernooij, CP (ITOPT1) - KLM]

Are you interested in the default jobclass of the INTRDR or in the jobclass 
your job will get if you don't specify one? Exits can modify the jobclass 
during/after submission.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gabor Hoffer
Sent: 07 December, 2015 15:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Inquire intrdr default job class

How can I inquire the internal reader characteristics from program (asm, c)?

$HASP838 INTRDR
$HASP838 INTRDR  AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),BATCH=YES,
$HASP838 CLASS=X,HOLD=NO,HONORLIM=NO,PRTYINC=0,
$HASP838 PRTYLIM=15,SYSAFF=(ANY),TRACE=NO

Actually, I'm interested in default job class.
Thanks in advance.

Gabor

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Gabor Hoffer]

Yes, it's the output from $DINTRDR, but I want to get it directly.
I'm wondering, if it can be inquired by SSI call or extracted from mvs/jes
data areas.

On Mon, Dec 7, 2015 at 3:57 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 7 Dec 2015 15:45:46 +0100, Lucas Rosalen wrote:
>
> >Looks like $DINTRDR would suffice or $DINTRDR,C. Check this out:
> >
> https://www-01.ibm.com/support/knowledgecenter/mobile/#!/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasa200/dintrdr.htm
> >
> How do you code that in ASM or C (OP's question).  I suppose MGCR in ASM
> (Is MGR now specified to support other than START or REPLY?)  How do
> you capture the output?
>
>
> >On Dec 7, 2015 15:33, "Gabor Hoffer" wrote:
> >
> >> How can I inquire the internal reader characteristics from program (asm,
> >> c)?
> >>
> >> $HASP838 INTRDR
> >> $HASP838 INTRDR  AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),BATCH=YES,
> >> $HASP838 CLASS=X,HOLD=NO,HONORLIM=NO,PRTYINC=0,
> >> $HASP838 PRTYLIM=15,SYSAFF=(ANY),TRACE=NO
> >>
> >> Actually, I'm interested in default job class.
> >> Thanks in advance.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On Mon, 7 Dec 2015 16:15:16 +0100, Gabor Hoffer wrote:

>Default jobclass of INTRDR, so before submit.
> 
Might that be available by tediously parsing a PARMLIB member?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[J O Skip Robinson]

Gil's point raises an issue more critical than just the question at hand. Once 
upon a time, 'reading JES2 parms' would have been a reasonable strategy in 
general for determining how JES2 runs. Since the advent of pervasive dynamic 
changes, however, the init deck as coded is no longer a reliable window into 
JES2 processing. A great many changes are now made simply by command. Old 
values are ignored on hot start and in many cases even on all-system warm 
start. Only a cold start will reinstate coded parm values that might actually 
be years out of date.

There is today no substitute for a display command with full detail. 



.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
OR
jo.skip.robin...@att.net
OR
jo.skip.robin...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, December 07, 2015 7:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Inquire intrdr default job class

On Mon, 7 Dec 2015 16:15:16 +0100, Gabor Hoffer wrote:

>Default jobclass of INTRDR, so before submit.
> 
Might that be available by tediously parsing a PARMLIB member?

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Elardus Engelbrecht]

Gabor Hoffer wrote:

>Yes, it's the output from $DINTRDR, but I want to get it directly.
>I'm wondering, if it can be inquired by SSI call or extracted from mvs/jes 
>data areas.

Ok. I will bite on this thread. What z/OS and JES2 level are you on?

What program language(s) do you want to use to get that info?

One way to do that is, as others said, issue a command (say with SVC 34 or 
similar) and then scrape the fat from the SYSLOG to get your info.

I don't like scanning the parmlib, because you may scan an outdated thing...

I believe there is a JES2 macro you can use, something like $SCAN macro or so. 
But note, I just mentioned $SCAN as an example, it does not say, you can use 
that. I hope someone else can give you a working example of a JES2 macro in 
Assembler.

DISCLAIMER - my knowledge of JES2 macros is somewhat badly rusty these days. 
Some serious polishing is waiting...

I wonder if there is a CBT freebie lurking which can do what you want...

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Shmuel Metz (Seymour J.)]

In <6022799404953725.wa.paulgboulderaim@listserv.ua.edu>, on
12/07/2015
   at 08:57 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>(Is MGR now specified to support other than START or REPLY?)

MGCR has always supported other than START or REPLY.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On Mon, 7 Dec 2015 12:35:47 -0500, Shmuel Metz (Seymour J.) wrote:

> on 12/07/2015 at 08:57 AM, Paul Gilmartin said:
>
>>(Is MGR now specified to support other than START or REPLY?)
>
>MGCR has always supported other than START or REPLY.
>
No:

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa300/mgcr.htm
...
Restrictions
You can use MGCR to issue only START or REPLY commands. You must use MGCRE 
for any other commands.

I can hardly imagine a more explicit statement of a restriction.  MGCRE is the 
alternative.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On 2015-12-07 09:58, J O Skip Robinson wrote:
> Gil's point raises an issue more critical than just the question at hand. 
> Once upon a time, 'reading JES2 parms' would have been a reasonable strategy 
> in general for determining how JES2 runs. Since the advent of pervasive 
> dynamic changes, however, the init deck as coded is no longer a reliable 
> window into JES2 processing. A great many changes are now made simply by 
> command. Old values are ignored on hot start and in many cases even on 
> all-system warm start. Only a cold start will reinstate coded parm values 
> that might actually be years out of date.
> 
> There is today no substitute for a display command with full detail. 
> 
More modern systems, often on desktops, have similar dynamic change
facilities.  However they often have a "Save as Default" checkbox
which does the equivalent of writing the changes back to the init
deck and making them persistent.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Anthony Thompson]

No, it's a JES2 thing. And therefore you will find the mapping DSECT for $IRIS 
in SHASMAC.

I think you can chase it down from the CVT by going through CVTJESCT to find 
the first SSCT (primary JES2) -> SSCTSUS2 -> HCCT (which is a sort of CVT for 
JES2, mapped by $HCCT)

Otherwise you can get to the SSCT for JES2 by going through the SSVT.


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, 8 December 2015 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inquire intrdr default job class

On Mon, 7 Dec 2015 18:40:56 -0600, Steve Horein  wrote:

>Found this in JES2 Data Areas Volume 1:
>
>Chapter 106. $IRIS Information
>$IRIS Programming Interface Information $IRIS is a programming 
>interface.
>$IRIS Heading Information
>Common Name: IRIS
>Macro ID: $IRIS
>DSECT Name: IRIS
>
This looks like an IPCS thing.

o Is it usable outside IPCS, perhaps by chasing pointers from CVT?

o What MACLIB does it live in?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Shmuel Metz (Seymour J.)]

In <5280778212763748.wa.paulgboulderaim@listserv.ua.edu>, on
12/07/2015
   at 11:46 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa300/mgcr.htm

I believe that you'll find stuff on the CBT tape using MGCR that still
works.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On Mon, 7 Dec 2015 14:15:45 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa300/mgcr.htm
>
>I believe that you'll find stuff on the CBT tape using MGCR that still
>works.
> 
Does IBM support "stuff on the CBT tape"?  Do I need to clarify that when I 
wrote
"supported" I meant supported by IBM, not by a group of dedicated volunteers
on a resource available basis?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On Mon, 7 Dec 2015 15:45:46 +0100, Lucas Rosalen wrote:

>Looks like $DINTRDR would suffice or $DINTRDR,C. Check this out:
>https://www-01.ibm.com/support/knowledgecenter/mobile/#!/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasa200/dintrdr.htm
>
>Lucas
>On Dec 7, 2015 15:33, "Gabor Hoffer" wrote:
>
>> How can I inquire the internal reader characteristics from program (asm,
>> c)?
>>
>> $HASP838 INTRDR
>> $HASP838 INTRDR  AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),BATCH=YES,
>> $HASP838 CLASS=X,HOLD=NO,HONORLIM=NO,PRTYINC=0,
>> $HASP838 PRTYLIM=15,SYSAFF=(ANY),TRACE=NO
>>
>> Actually, I'm interested in default job class.
>> Thanks in advance.


OK.  Here's an example using SDSF services:

user@OS/390.24.00: cat ISFOPER  

/* Rexx */ signal on novalue;  /*
   Doc: Issue operator command via ISFSLASH; reply to stdout.

   See (strangely enough):
   Document Number SA22-7670-11
   #12.0 "z/OS V1R10.0 SDSF Operation and Customization"
12.0 Using SDSF with the REXX programming language
*/
trace Err

RC = ISFCALLS( 'ON' )
address 'SDSF'

Arg1.0 = 1
Arg1.1 = arg( 1 )
if Arg1.1=='' then address 'ISREDIT' 'MACRO (Arg1.1)'

'isfexec ISFULOG'
'ISFSLASH (Arg1.)'
do I = 1 to ISFULOG.0;  say ISFULOG.I;  end I
exit( RC )
user@OS/390.24.00:


Invoked under UNIX system services, it writes to stdout:

user@OS/390.24.00: ISFOPER '$dintrdr'   

MVS3  2015341  14:04:42.16 ISF041I CONSOLE NAME user MODIFIED
MVS3  2015341  14:04:42.16 ISF031I CONSOLE user$ ACTIVATED
MVS3  2015341  14:04:42.16-$dintrdr
MVS3  2015341  14:04:42.17 $HASP838 INTRDR
   $HASP838 INTRDR  
AUTH=(DEVICE=YES,JOB=YES,SYSTEM=YES),BATCH=YES,
   $HASP838 
CLASS=A,HOLD=NO,HONORLIM=NO,PRTYINC=0,
   $HASP838 
PRTYLIM=15,SYSAFF=(ANY),TRACE=NO
user@OS/390.24.00:

Tedious plumbing with, e.g. BPX1PIP and BPX1SPN is left as an exercise
for the student.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Steve Horein]

Found this in JES2 Data Areas Volume 1:

Chapter 106. $IRIS Information
$IRIS Programming Interface Information
$IRIS is a programming interface.
$IRIS Heading Information
Common Name: IRIS
Macro ID: $IRIS
DSECT Name: IRIS
Owning Component: JES2 (SC1BH)
Eye-Catcher ID: IRIS
Offset: IRSEYE-IRS
Length: L’IRSEYE
Storage Attributes: Subpool: 241
Key: 1
Residency: Virtual storage is in 31 bit storage, real can be in
64 bit storage, in common storage
Size: See IRISLEN
Created by: HASPIRMA during JES2 initialization processing
Pointed to by: CCTBATMD field of the HCCT data area
CCTIRSMD field of the HCCT data area
CCTSTCMD field of the HCCT data area
CCTTSOMD field of the HCCT data area
Serialization: None required
Function: This area maps the data area used to store defaults
for internal readers (as set from INTRDR
initialization statement). One exists for each type
of internal reader (in ECSA) even though the
initialization statement only applies to batch
internal readers.

I'm no longer in a JES2 shop, so I can't easily play.

On Mon, Dec 7, 2015 at 9:19 AM, Gabor Hoffer  wrote:

> Yes, it's the output from $DINTRDR, but I want to get it directly.
> I'm wondering, if it can be inquired by SSI call or extracted from mvs/jes
> data areas.
>
> On Mon, Dec 7, 2015 at 3:57 PM, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Mon, 7 Dec 2015 15:45:46 +0100, Lucas Rosalen wrote:
> >
> > >Looks like $DINTRDR would suffice or $DINTRDR,C. Check this out:
> > >
> >
> https://www-01.ibm.com/support/knowledgecenter/mobile/#!/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasa200/dintrdr.htm
> > >
> > How do you code that in ASM or C (OP's question).  I suppose MGCR in ASM
> > (Is MGR now specified to support other than START or REPLY?)  How do
> > you capture the output?
> >
> >
> > >On Dec 7, 2015 15:33, "Gabor Hoffer" wrote:
> > >
> > >> How can I inquire the internal reader characteristics from program
> (asm,
> > >> c)?
> > >>
> > >> $HASP838 INTRDR
> > >> $HASP838 INTRDR  AUTH=(DEVICE=NO,JOB=NO,SYSTEM=NO),BATCH=YES,
> > >> $HASP838 CLASS=X,HOLD=NO,HONORLIM=NO,PRTYINC=0,
> > >> $HASP838 PRTYLIM=15,SYSAFF=(ANY),TRACE=NO
> > >>
> > >> Actually, I'm interested in default job class.
> > >> Thanks in advance.
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Paul Gilmartin]

On Mon, 7 Dec 2015 18:40:56 -0600, Steve Horein  wrote:

>Found this in JES2 Data Areas Volume 1:
>
>Chapter 106. $IRIS Information
>$IRIS Programming Interface Information
>$IRIS is a programming interface.
>$IRIS Heading Information
>Common Name: IRIS
>Macro ID: $IRIS
>DSECT Name: IRIS
>
This looks like an IPCS thing.

o Is it usable outside IPCS, perhaps by chasing pointers from CVT?

o What MACLIB does it live in?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inquire intrdr default job class

[Shmuel Metz (Seymour J.)]

In <8713351764061408.wa.paulgboulderaim@listserv.ua.edu>, on
12/07/2015
   at 02:43 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>On Mon, 7 Dec 2015 14:15:45 -0500, Shmuel Metz (Seymour J.) wrote: >
>>>https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa300/mgcr.htm
>>
>>I believe that you'll find stuff on the CBT tape using MGCR that still
>>works.
>> 
>Does IBM support "stuff on the CBT tape"? 

Are you holding yet another sale of red herrings?

>Do I need to clarify that when I wrote
>"supported" I meant supported by IBM, not by a group of dedicated
>volunteers on a resource available basis?

No, but it would help if you understand that breaking working code in
order to use a newer interface is not always the best idea.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN