Re: System symbols in batch JCL

[John McKown]

On Fri, Jul 22, 2016 at 2:36 PM, Jesse 1 Robinson 
wrote:

> I think Peter is on the right track. I normally do not code any CLASS= on
> a job. Execution class here gets set by some pretty involved code in Exit
> 6, but the question is what 'jobclass' is used for options during
> conversion?
>
> If I omit CLASS=, my job works, implying that 'class A' rules are in
> effect. Changing nothing else, I added CLASS=C (unmodified) to the job
> card, and I get the same 'invalid use of ampersand' error that I started
> with. Then I set JOBCLASS(C) to allow SYSSYM, and the job worked.
>
> So again, what determines conversion rules if no CLASS= is coded? I cannot
> find any parameter in our JES2 init deck that would set class A as the
> default.
>

​Not necessarily definitive, due to language
ref:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/iea3b6_Defaults47.htm



If you do not specify the CLASS keyword, JES uses the installation default
specified at initialization, as follows:

   - In a JES2 system, the default is based on the source of the job: The
   system makes the job’s class the same as the installation-specified default
   class for the particular card reader, work station, or time-sharing user
   that submitted the job.
   - In a JES3 system, the default is an installation-defined standard
   default class.



​
​Looking at the above, I would guess that you are submitting this from TSO.
So it would be the default in your TSO segment in RACF.
ref:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha700/tsosup.htm
Does not answer the question if the JOBCLASS entry in the TSO segment is
not entered.
futher information:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasa400/has2u600110.htm


DEF_CLASS=class|A[image: End of change][image: Start of change]Specifies a
default class that JES2 will use if a non-valid class is discovered during
processing. The specified class must be a defined and active batch job
class. The specified class cannot be set to ACTIVE=NO, and cannot be
deleted. The following examples show when the default class would be used:

   - When a job is submitted with a CLASS= value that is not valid. The job
   is failed, but this class is associated with the job for later processing.
   - When a job class is deleted that is associated with the INTRDR
   statement as CLASS=. The INTRDR CLASS value is set to this value.
   - During initialization processing, when the CLASS= value that is
   specified for a reader (INTRDR, local or remote) is not valid and the
   operator continues initialization.

The default is A.


​




>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

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: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[CM Poncelet]

A S0C4-4 would occur only if there were a storage access violation. The 
S0C4-11 implies that it is a page translation exception - i.e. that this 
4K page has not been allocated within an already allocated segment (else 
would have S0C4-10). A S0C1 would have occurred only if the S0C4-11 had 
not happened first and executing the instruction x'' at  had 
then failed. So why was the page not allocated and what executable code 
should have been loaded into it - or is its  address corrupted? 
(The x'' seems to be left-over garbage.) BTW Why load offset x'90' 
on R7 as EP?


My ha'pennyworth. CP

Peter Hunkeler wrote:


The storage R7 point to, and the storage at offset x'90' is in SP251 key 8. It 
is part of a load module. The fullword at R7+x'90' is the value seen in the 
PSW, so both the L as well as the BASSM have been executed. The program fails 
when the CP is accessing the instruction at the PSW's NSI. The storage at this 
address is a couple of x'00', and the storage is in SP1, key 8.
If anyting was allocated but not accessible, a S0C4-4 would occur, not an 
S0C4-11.
--Peter Hunkeler


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler 
Sent: 22 July, 2016 15:51 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: S0C4-11 abend caused by BASSM to address with all X'00' bytes 

I'm confused. Can I not see the obvious? 



We've got an S0C4-11 abend in a batch job. The last instructions seem to be  

L R15,x'90'(,7) 
BASSM R14,R15 

R15 has the address that is seen in the PSW in the dump. The storage at this address *is* in the dump, and it contains a couple of X'00'.  



How can the storage be in the dump when the abend code suggests it is not even getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by X'' at the PSW NSI address)? 



The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in SP 1, key 8. 



Any hint what I'm missing? 








 



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

Re: System symbols in batch JCL

[Bob Rutledge]

I would expect that behavior for TYPRUN=HOLD; how about TYPRUN=JCLHOLD?

Bob

On 7/22/2016 5:03 PM, Jesse 1 Robinson wrote:

Ed knows I was just kidding. More grist for your sysprog notebook.

-- If a job is submitted with TYPRUN=HOLD, system symbols are substituted 
immediately during conversion.
-- If a job is submitted with SYSAFF=inactive-system, there is no substitution 
because (I guess) no conversion.

Case 2 is probably what you'd expect, but Case 1 is one of those canned worms I 
spoke of earlier. Surely I would like a DSN date/time stamp to reflect 
execution date/time, not submit date/time, but the latter is what I get. More 
uproar at the convention.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, July 22, 2016 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: System symbols in batch JCL

On 7/22/2016 1:54 PM, Jesse 1 Robinson wrote:

Thanks to all. I'll be quiet now.


Haha! I likely story ...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


--
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: AW: Re: Interface to query length of storage allocated with CEEGTST LE service

[Steve Smith]

As far as memory (storage) references go, "Above" and "Below" can easily be
perceived and defended either way, although *I* would usually take "Above"
to mean higher addresses (cf. "above-the-line').  By context, I guess the
opposite was meant, probably by projection of a dump or most memory
displays.  Anyway, the terms, they are ambiguous.

I think "Before" and "After" are much clearer.

sas

On Fri, Jul 22, 2016 at 4:35 PM, J R  wrote:

> Of my vast collection of laptops, I use only the most recent two.  One
> started life under W7, the other under W8.  Of course, MS eventually
> cajoled me into "upgrading" them both to W10!  Their scrolling-by-gesture
> works in opposite directions and I have yet to bother fixing one to match
> the other.  Consequently, it always takes a few swipes to figure which way
> to scroll.
>
> So, it's not just Apple; MS has blindly followed, but not yet
> standardized.  :-(
>
> Sent from my iPhone
>
> > On Jul 22, 2016, at 13:23, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Somewhat like ISPF scrolling.  A couple releases ago, Apple reversed the
> conventions
> > of scrolling-by-gesture in OS X (optionally, but default) to be
> compatible with iOS.
> >
> > But still, I wondered if it arose from a desire to page-align the base
> of the area.
> >
> > -- gil
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: System symbols in batch JCL

[Edward Finnell]

No roar at all-WAD.
 
 
In a message dated 7/22/2016 4:03:18 P.M. Central Daylight Time,  
jesse1.robin...@sce.com writes:

More  uproar at the convention. 


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

Re: System symbols in batch JCL

[Jesse 1 Robinson]

Ed knows I was just kidding. More grist for your sysprog notebook.

-- If a job is submitted with TYPRUN=HOLD, system symbols are substituted 
immediately during conversion.
-- If a job is submitted with SYSAFF=inactive-system, there is no substitution 
because (I guess) no conversion.

Case 2 is probably what you'd expect, but Case 1 is one of those canned worms I 
spoke of earlier. Surely I would like a DSN date/time stamp to reflect 
execution date/time, not submit date/time, but the latter is what I get. More 
uproar at the convention. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, July 22, 2016 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: System symbols in batch JCL

On 7/22/2016 1:54 PM, Jesse 1 Robinson wrote:
> Thanks to all. I'll be quiet now.

Haha! I likely story ...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


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

Re: System symbols in batch JCL

[Ed Jaffe]

On 7/22/2016 1:54 PM, Jesse 1 Robinson wrote:

Thanks to all. I'll be quiet now.


Haha! I likely story ...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: System symbols in batch JCL

[Jesse 1 Robinson]

It's all coming together. We do not specify any class in JES2 for INTRDR, so it 
defaults to A.

For users defined via either UADS or TSOE segment, class is specified as A.

Thanks to all. I'll be quiet now.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Friday, July 22, 2016 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: System symbols in batch JCL

INTRDR
 

>--+---+--++>

   | .-A-. |  |.-No--. |   

   '-,Class=-+-v-+-'  '-,Hold=-+-Yes-+-'   



>--++--+--+->

   '-,HONORlim=-+-No--+-'  |   .-0--. |   

'-Yes-''-,PRTYINC=-+-nn-+-'   



>--+--+--+-+|

   |   .-15-. |  | .-No--. |   

   '-,PRTYLIM=-+-nn-+-'  '-,TRace=-+-P---+-'   

   '-Yes-' 







In a message dated 7/22/2016 2:36:53 P.M. Central Daylight Time, 
jesse1.robin...@sce.com writes:

So  again, what determines conversion rules if no CLASS= is coded? I cannot 
find  any parameter in our JES2 init deck that would set class A as the default

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

Upcoming Share Conference events in 2017

[Lizette Koehler]

I just thought I would let you know the dates and locations for SHARE in 2017.
This way you can plan in advance.

Share.org

SHARE San Jose
San Jose McEnery Convention Center
San Jose, CA
March 5-10, 2017


SHARE Providence
Rhode Island Convention Center
Providence, RI
August 6-11, 2017



Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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

Re: EXTERNAL: Re: System symbols in batch JCL

[Jerry Whitteridge]

I do see that we change our default class in the INTRDR statement

/*   */
 INTRDR  AUTH=(JOB=YES,   /* AUTHORITY TO SUBMIT COMMANDS*/
   DEVICE=YES,
   SYSTEM=YES),
 BATCH=YES,   /* CAN PROCESS BATCH JOBS TOO  */
 CLASS=C, /* DEFAULT JOBCLASS IF SPECIFIED   */
 HOLD=NO, /* DO NOT HOLD JOBS AFTER CONVERSN */
 PRTYINC=0,   /* WHAT TO ADD TO PRIORITY */
 PRTYLIM=15,  /* MAX LIMIT THAT CAN BE SPECIFIED */
 HONORLIM=NO, /* DOES INTRDR HAVE TO LIMIT JOB?  */
 TRACE=NO /* DO NOT TRACE AT STARTUP */


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 Jerry Whitteridge
Sent: Friday, July 22, 2016 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: System symbols in batch JCL

Lots of vague memories indicate CLASS=A to be the default class if no class is 
specified - but I currently have no doc that indicates that (I'm still digging).

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 Jesse 1 Robinson
Sent: Friday, July 22, 2016 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: System symbols in batch JCL

I think Peter is on the right track. I normally do not code any CLASS= on a 
job. Execution class here gets set by some pretty involved code in Exit 6, but 
the question is what 'jobclass' is used for options during conversion?

If I omit CLASS=, my job works, implying that 'class A' rules are in effect. 
Changing nothing else, I added CLASS=C (unmodified) to the job card, and I get 
the same 'invalid use of ampersand' error that I started with. Then I set 
JOBCLASS(C) to allow SYSSYM, and the job worked.

So again, what determines conversion rules if no CLASS= is coded? I cannot find 
any parameter in our JES2 init deck that would set class A as the default.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Friday, July 22, 2016 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):AW: Re: System symbols in batch JCL

If anyone is still paying attention, my question lingers. Is CLASS A always 
used for JCL conversion? Just because it's first in the list? Is it a defined 
or default option? If it's always gonna be CLASS A, do I need to 'ALLOW' any 
other class?



The conversion is not done by a class, its done by the conversion code. The 
CLASS only tells limits and defaults. If you allow SYSSYM on class A but not on 
class B, conversion will fail to resolve symbols if CLASS=B is coded on the job 
statement, but will do it for CLASS=A.


In your case, the symbol resolution is probably done before something changes 
the CLASS form A to C.


--
Peter Hunkeler

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), 

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Tony Harminc]

On 22 July 2016 at 14:32, Ed Jaffe  wrote:
>> Just curious that the PER bit is on. Was someone running a SLIP of a
>> PERish sort?
>
> These days the PER bit is *always* on, in any serious development/test
> environment, because of the ever-present ZAD SLIP in effect.

Sure - I'm used to seeing the bit on on my own systems. But I
understood -- perhaps incorrectly -- that this dump came from a
customer environment, and that that at least partly explains the
difficulty in getting a "real" SVC/SLIP dump. Presumably a production
environment is far less likely to have any kind of PER running.
Certainly we rarely see it on in customer dumps unless it's from a
SLIP we've asked them to set.

Tony H.

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

Re: System symbols in batch JCL

[Edward Finnell]

INTRDR
 

>--+---+--++>

   | .-A-. |  |.-No--. |   

   '-,Class=-+-v-+-'  '-,Hold=-+-Yes-+-'   



>--++--+--+->

   '-,HONORlim=-+-No--+-'  |   .-0--. |   

'-Yes-''-,PRTYINC=-+-nn-+-'   



>--+--+--+-+|

   |   .-15-. |  | .-No--. |   

   '-,PRTYLIM=-+-nn-+-'  '-,TRace=-+-P---+-'   

   '-Yes-' 







In a message dated 7/22/2016 2:36:53 P.M. Central Daylight Time,  
jesse1.robin...@sce.com writes:

So  again, what determines conversion rules if no CLASS= is coded? I cannot 
find  any parameter in our JES2 init deck that would set class A as the 
default.  



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

Re: EXTERNAL: Re: System symbols in batch JCL

[Jerry Whitteridge]

Lots of vague memories indicate CLASS=A to be the default class if no class is 
specified - but I currently have no doc that indicates that (I'm still digging).

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 Jesse 1 Robinson
Sent: Friday, July 22, 2016 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: System symbols in batch JCL

I think Peter is on the right track. I normally do not code any CLASS= on a 
job. Execution class here gets set by some pretty involved code in Exit 6, but 
the question is what 'jobclass' is used for options during conversion?

If I omit CLASS=, my job works, implying that 'class A' rules are in effect. 
Changing nothing else, I added CLASS=C (unmodified) to the job card, and I get 
the same 'invalid use of ampersand' error that I started with. Then I set 
JOBCLASS(C) to allow SYSSYM, and the job worked.

So again, what determines conversion rules if no CLASS= is coded? I cannot find 
any parameter in our JES2 init deck that would set class A as the default.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Friday, July 22, 2016 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):AW: Re: System symbols in batch JCL

If anyone is still paying attention, my question lingers. Is CLASS A always 
used for JCL conversion? Just because it's first in the list? Is it a defined 
or default option? If it's always gonna be CLASS A, do I need to 'ALLOW' any 
other class?



The conversion is not done by a class, its done by the conversion code. The 
CLASS only tells limits and defaults. If you allow SYSSYM on class A but not on 
class B, conversion will fail to resolve symbols if CLASS=B is coded on the job 
statement, but will do it for CLASS=A.


In your case, the symbol resolution is probably done before something changes 
the CLASS form A to C.


--
Peter Hunkeler

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

Re: System symbols in batch JCL

[Tom Marchant]

On Fri, 22 Jul 2016 19:36:39 +, Jesse 1 Robinson wrote:

>So again, what determines conversion rules if no CLASS= is coded? I cannot 
>find any parameter in our JES2 init deck that would set class A as the 
>default. 

From the JCL Reference under the CLASS parameter on the JOB card:


In a JES2 system, the default is based on the source of the job: The system 
makes the job's class the same as the installation-specified default class for 
the particular card reader, work station, or time-sharing user that submitted 
the job.


-- 
Tom Marchant

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

Re: System symbols in batch JCL

[Jesse 1 Robinson]

I think Peter is on the right track. I normally do not code any CLASS= on a 
job. Execution class here gets set by some pretty involved code in Exit 6, but 
the question is what 'jobclass' is used for options during conversion?

If I omit CLASS=, my job works, implying that 'class A' rules are in effect. 
Changing nothing else, I added CLASS=C (unmodified) to the job card, and I get 
the same 'invalid use of ampersand' error that I started with. Then I set 
JOBCLASS(C) to allow SYSSYM, and the job worked.  

So again, what determines conversion rules if no CLASS= is coded? I cannot find 
any parameter in our JES2 init deck that would set class A as the default. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Friday, July 22, 2016 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):AW: Re: System symbols in batch JCL

If anyone is still paying attention, my question lingers. Is CLASS A always 
used for JCL conversion? Just because it's first in the list? Is it a defined 
or default option? If it's always gonna be CLASS A, do I need to 'ALLOW' any 
other class? 
 


The conversion is not done by a class, its done by the conversion code. The 
CLASS only tells limits and defaults. If you allow SYSSYM on class A but not on 
class B, conversion will fail to resolve symbols if CLASS=B is coded on the job 
statement, but will do it for CLASS=A.


In your case, the symbol resolution is probably done before something changes 
the CLASS form A to C. 


--
Peter Hunkeler

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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Blaicher, Christopher Y.]

Just a thought -
Could the area R15 points to have been allocated by one of those "we'll figure 
out your problem for you" routines after the 0C4-11 and before the dump so that 
when you look in the dump they provide it looks like you should have gotten an 
0C1 rather than an 0C4-11?

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, July 22, 2016 2:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

On 7/22/2016 9:31 AM, Tony Harminc wrote:
>
> Just curious that the PER bit is on. Was someone running a SLIP of a
> PERish sort?

These days the PER bit is *always* on, in any serious development/test 
environment, because of the ever-present ZAD SLIP in effect.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Ed Jaffe]

On 7/22/2016 8:14 AM, Peter Hunkeler wrote:

What are the full contents of the 128-bit PSW? What's the 64-bit TEA value?
  


I got a CEEDUMP and an analysis from StartTool DA.


Oh gawd. This is where I shrug my shoulders and wash my hands of it. I 
like SVC dumps with all storage dumped and nice long trace tables. 
Anything else is just frustration in a can!


Good luck...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Ed Jaffe]

On 7/22/2016 9:31 AM, Tony Harminc wrote:


Just curious that the PER bit is on. Was someone running a SLIP of a
PERish sort?


These days the PER bit is *always* on, in any serious development/test 
environment, because of the ever-present ZAD SLIP in effect.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Ed Jaffe]

On 7/22/2016 8:36 AM, Charles Mills wrote:

Ah! Wait! The exact discussion was about a S0C6 on a branch to an odd
address. Not sure if this would behave the same. Someone surely knows, and
almost as surely will correct me if I am wrong.


IIRC, the question was whether the 0C6 from the odd PSW address would 
take precedence over the 0C4 for inability to fetch instructions from 
the target location. The answer was yes.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Tom Marchant]

On Fri, 22 Jul 2016 18:23:04 +0200, Peter Hunkeler  wrote:

>>If you show the exact information from the dump, rather than your 
>>interpretation of that data, there is a better chance that someone will be 
>>able to see something that you didn't.
>
>
>I'll happily show any data you ask me specifically. I would not know what to 
>post otherwise; It simply too much data.

You provided analysis of some data. If you had provided the data that you used 
to arrive at the conclusions that you did, that would have been helpful. It may 
have led to a request for more data, but at least we would have had a place to 
start. You've shown the PSW. You haven't shown the data at and before the PSW. 
Do you have the ILC?

-- 
Tom Marchant

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

AW: Re: AW: Re: Setting dump options for SVC dumps taken by StarTool DA-Batch?

[Peter Hunkeler]

Great! Just the information I was looking for!

Now I just need to convince our engineers to actually do it.

And yes, I have been debugging using this dump in IPCS. This is how I found out 
that TRT is not specified in the SDUMP macro.


--
Peter Hunkeler



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

Re: AW: Re: Interface to query length of storage allocated with CEEGTST LE service

[Paul Gilmartin]

On Fri, 22 Jul 2016 11:59:33 -0500, Victor Gil wrote:

>No, subtract 8-16 bytes from the area address to get to the header...
>
>I guess my usage of the words "top" and "ABOVE" could be misleading - this is 
>how we were drawing memory maps back in the 70s, so that they grow DOWN from 
>the staring location
> 
And Bill Waite teaching a CS class circa 1972 would sketch a memory map on the
chalkboard and describe it, saying "Up" and pointing to the floor; "Down" and 
pointing
to the ceiling.  Algebra vs. geometry.

Somewhat like ISPF scrolling.  A couple releases ago, Apple reversed the 
conventions
of scrolling-by-gesture in OS X (optionally, but default) to be compatible with 
iOS.

But still, I wondered if it arose from a desire to page-align the base of the 
area.

-- gil

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

AW: Re: System symbols in batch JCL

[Peter Hunkeler]

If anyone is still paying attention, my question lingers. Is CLASS A always 
used for JCL conversion? Just because it's first in the list? Is it a defined 
or default option? If it's always gonna be CLASS A, do I need to 'ALLOW' any 
other class?



The conversion is not done by a class, its done by the conversion code. The 
CLASS only tells limits and defaults. If you allow SYSSYM on class A but not on 
class B, conversion will fail to resolve symbols if CLASS=B is coded on the job 
statement, but will do it for CLASS=A.


In your case, the symbol resolution is probably done before something changes 
the CLASS form A to C.


--
Peter Hunkeler



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

AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Peter Hunkeler]

>Just curious that the PER bit is on. Was someone running a SLIP of a
>PERish sort? Any chance of a dump or trace from that, or is the toy
>dump all you have to work with?


Made me wondering as well, but I have not checked the SLIPs yet. I doubt there 
is a SLIP for this job, so the SLIP is set to be not limited for the target 
job(s), only. Bad, IMHO.


I did check if there is another SVc dump from that time around which could have 
provided me the missing system trace, but Murphy made sure there is none.


So yes, for the time being I'm left with the toy dumps.


--
Peter Hunkeler


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

AW: Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Peter Hunkeler]

>The most likely explanation is that the target address of the BASSM
>was not GETMAINed storage at the time of the abend (causing the
>0C4-11 abend), but was subsequently GETMAINed and used before the dump
>was initiated or as part of the dump processing.


Yes, I had thought about this possibilty as well. The storage where the PSW NSI 
point to seems to be part of a chain of 4k areas. I see what looks like forward 
and backward pointers near the beginning of each 4k area. I also see the name 
of some of the applicaition modules that are loaded, as well as the lliters 
PCONTROL in each of the blocks. Some bytes before the first such block, there 
is the literal HANC, which indicates this might be LE heap storage.


For all this, I thought the storage must have been there before the S0C4, but 
of course this linked list can as well have been built as part of Smart/Restart 
or StarTool analysis. But is seemed unlikely to be that tools bilt to analyze 
failures would tell me false information. But again, who knows.


If I only had the system trace. It would all be so much easier. I cannot 
understand how someone coding an SDUMP macro can leave away TRT and explicitly 
specify that dump defaults and change dump options shall be ignored (seen in 
the SVC dump, dicussed in a separate thread).


Thanks for your help so far. I'll restart posting on Monday, if I have new 
questions or new information with wich you could help me.




--
Peter Hunkeler



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

Re: AW: Re: Interface to query length of storage allocated with CEEGTST LE service

[Victor Gil]

No, subtract 8-16 bytes from the area address to get to the header...

I guess my usage of the words "top" and "ABOVE" could be misleading - this is 
how we were drawing memory maps back in the 70s, so that they grow DOWN from 
the staring location


On Fri, 22 Jul 2016 08:53:54 -0500, Victor Gil wrote:

>I am guessing the length may be stored somewhere in the vicinity of the area 
>top address, say within 8-16 bytes ABOVE it.
> 
So to get to it you just add the length of the area to the address of the area?

>At least this is how CICS handles GETMAIN requests which also don't require 
>length on the FREEMAINs.
>
>Of course, if the convention is not documented it may change at any time ...

-- gil

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

Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Jim Mulder]

> I'm not asking for help to solve that actual problem that 
> application has had and which caused the dump. I'm looking for help 
> to undestand why we get the S0C4-11 when I had expected an S0C1. I 
> trust once I understand this, I'll be able to continue debugging the 
problem.

  The most likely explanation is that the target address of the BASSM
was not GETMAINed storage at the time of the abend (causing the
0C4-11 abend), but was subsequently GETMAINed and used before the dump 
was initiated or as part of the dump processing. 

Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. 
Poughkeepsie, NY


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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Tony Harminc]

On 22 July 2016 at 11:14, Peter Hunkeler  wrote:
> I got a CEEDUMP and an analysis from StartTool DA. Both tell me the failing 
> PSW is 478D0400 A31A7BB8
> Looking at the SVC dump at the PRB/XSB which is now producing the SVC dump 
> (WLIC is 00020033), I see:
> XSB+00E0  PSW16 47850400  8000    231A7BB8

Just curious that the PER bit is on. Was someone running a SLIP of a
PERish sort? Any chance of a dump or trace from that, or is the toy
dump all you have to work with?

Tony H.

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

Re: System symbols in batch JCL

[Jesse 1 Robinson]

As Ed notes, batch support for system symbols is (was?) new in 2.1. Over the 
years I've participated in SHARE forum discussions on this issue. Unlike STC 
and TSO, batch jobs introduce all sorts of variable and unpredictable 
conditions.

-- When does a submitted job actually execute?
-- Where does a submitted execute?
-- Under which of a myriad other conditions does a submitted job execute?

Various folks strongly expressed incompatible opinions on when/where/how 
symbols should be resolved. I was frankly surprised that IBM finally bit the 
bullet and committed to batch support. Can o worms.

I just now got into this because someone asked for a date/time stamp in a DSN. 
My first reaction was to use a Rexx. Then I got to wondering if that was still 
necessary.

If anyone is still paying attention, my question lingers. Is CLASS A always 
used for JCL conversion? Just because it's first in the list? Is it a defined 
or default option? If it's always gonna be CLASS A, do I need to 'ALLOW' any 
other class?

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, July 22, 2016 7:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: System symbols in batch JCL

On 7/22/2016 6:06 AM, Tom Marchant wrote:
>
> Or, if you use SDSF, go to the JC panel. All of the JOBCLASS attributes are 
> shown for all job classes in a tabular format. Scroll until you find the 
> SysSym column. Or use the Locate command:
>
> L SysSym
>
> I suspect (E)JES has similar support, but don't know how to access it.

'CL' command (or 'JC' alias) followed by 'LC SYSSYM'

(E)JES uses 'LC' for locating columns because 'L' is used for locating rows 
just like in other areas of ISPF.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


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

AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Peter Hunkeler]

>If you show the exact information from the dump, rather than your 
>interpretation of that data, there is a better chance that someone will be 
>able to see something that you didn't.


I'll happily show any data you ask me specifically. I would not know what to 
post otherwise; It simply too much data.


I'm not asking for help to solve that actual problem that application has had 
and which caused the dump. I'm looking for help to undestand why we get the 
S0C4-11 when I had expected an S0C1. I trust once I understand this, I'll be 
able to continue debugging the problem.


It's embarrassing how rusty my dump reading skills have become.


--
Peter Hunkeler




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

Re: AW: Re: Interface to query length of storage allocated with CEEGTST LE service

[Paul Gilmartin]

On Fri, 22 Jul 2016 08:53:54 -0500, Victor Gil wrote:

>I am guessing the length may be stored somewhere in the vicinity of the area 
>top address, say within 8-16 bytes ABOVE it.
> 
So to get to it you just add the length of the area to the address of the area?

>At least this is how CICS handles GETMAIN requests which also don't require 
>length on the FREEMAINs.
>
>Of course, if the convention is not documented it may change at any time ...

-- gil

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

Re: AW: Re: Setting dump options for SVC dumps taken by StarTool DA-Batch?

[Joe Prosser]

Hi,
There is a way to add/update SVC dump SDATA parameters to StarTool DA. It 
requires modifying and regenerating the DA MVS Control Table (MCT). Here are 
the instructions:

1)  Locate the StarTool DA installation datasets. These are the datasets 
created during the StarTool DA installation/configuration process. The datasets 
are named as follows:
.STRDA.V5R7Mn.
Where  is the user-defined high-level qualifier 
specified during DA configuration, ‘n’ is the mod level (should be a 2 or 3), 
and the  we are interested in are INSTALL and MACLIB.
2)  Edit the ESPYMCC1 module found in MACLIB. Add/update any desired SDATA 
parameters (e.g. add TRT).
3)  Locate member ESnnI000 in the DA INSTALL dataset, where ‘nn’ is the 
user-defined DA configuration id.
4)  In ESnnI000, find the title ‘Generate EMCT modules.’. Note the member 
name on the far left and execute this job to regenerate the MCTs.
5)  Restart the StarTool Workload Server. This job should be named ESnnWLS 
(where ‘nn’ is the DA configuration id).
6)  Run the batch job creating the abend. You should now see the trace in 
the dump.

Note that StarTool DA creates the SVC dump dataset for the Debugging and Viewer 
Service (DVS), but can also be read by IPCS. The SVC dump created is shown in 
the abending batch joblog under the ‘StarTool-DA Batch’ banner.

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

AW: Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Peter Hunkeler]

>How about the TRNE and BEA fields in that same XSB?




I seem to remember to have had a look a the BEA address and it matched with the 
BASSM. Will double check. on Monday when back in the office. Will also have a 
look at the TRNE then.


There is LE, Smart/Restart and StarTool DA which actively try to get their say. 
As long as I don't understand where the S0C4-11 comes from, I don't trust the 
information I see in the dumps. It's too foggy which code does what and when 
during recovery.


We're trying to repoduce the case in test so I can switch off all those little 
(sometimes useless) helpers.


--
Peter Hunkeler


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

Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Tom Conley]

On 7/22/2016 10:21 AM, Peter Hunkeler wrote:

 The storage R7 point to, and the storage at offset x'90' is in SP251 key 8. It 
is part of a load module. The fullword at R7+x'90' is the value seen in the 
PSW, so both the L as well as the BASSM have been executed. The program fails 
when the CP is accessing the instruction at the PSW's NSI. The storage at this 
address is a couple of x'00', and the storage is in SP1, key 8.
If anyting was allocated but not accessible, a S0C4-4 would occur, not an 
S0C4-11.
--Peter Hunkeler




You say it's in the load module.  Did you violate reentrancy?

Regards,
Tom Conley

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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Charles Mills]

Completes. The system takes a S0C4 when it tries to execute the inaccessible
instruction. It's a pedantic difference but important if you are shooting a
problem.

Some discussion here recently.

Ah! Wait! The exact discussion was about a S0C6 on a branch to an odd
address. Not sure if this would behave the same. Someone surely knows, and
almost as surely will correct me if I am wrong.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Vernooij, CP (ITOPT1) - KLM
Sent: Friday, July 22, 2016 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

No? What does a wild branch to unavailable storage do then?
--
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: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Jim Mulder]

> >What are the full contents of the 128-bit PSW? What's the 64-bit TEA 
value?
> 
> 
> I got a CEEDUMP and an analysis from StartTool DA. Both tell me the 
> failing PSW is478D0400 A31A7BB8 Looking at the SVC dump at the PRB/
> XSB which is now producing the SVC dump (WLIC is 00020033), I see:
> XSB+00E0  PSW16 47850400  8000    231A7BB8
> 
> Seems to match.
> 
> Unfortunately, there is no LOGREC entry in the dump for this error, 
> the system trace table has not been dumped (Grrr...), and there is 
> no SDWA in the dump. I'm lost how to find the TEA in this case.

  How about the TRNE and BEA fields in that same XSB? 

Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. 
Poughkeepsie, NY


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

Re: OS ENQ from COBOL

[Hardee, Chuck]

While that would be an interesting way to invoke the code, I suspect there 
would be less chance of that being supported should something happen to me than 
an assembler language subroutine.

Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Victor Gil
Sent: Friday, July 22, 2016 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OS ENQ from COBOL

There is a weird way to embed subroutines in machine instructions right into 
Cobol code by:

a) defining them [fully assembled] as a WORKING-STORAGE literal
b) setting address of a PROCEDURE-POINTER to address of that literal
c) calling the PROCEDURE-POINTER

And no, I don't recommend you actually use this approach, unless really 
desperate.

-Victor-  


Hello Listers,

First off, does anyone know of an IBM COBOL related list? If so, could you 
point me in that direction.

Now, to my question.

I can code an assembler solution, or even a hybrid COBOL/Assembler solution, 
but what I would truly love would be a COBOL only solution.
My need is to be able to determine if a QNAME/RNAME combination is held by 
another address space in the system.
Stated another way, is there any way to use an "ENQ 
(QNAME,RNAME,S,SYSTEM),REQ=TEST" from a COBOL program using COBOL only 
procedural statements?

As I said, I can code an assembler program to issue the ENQ, but because I may 
not always be the one supporting the code, I need to keep it in a language most 
of our shop knows.

In another direction, is there an LE service routine that could issue the ENQ 
TEST?

Thanks to All,
Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | 
www.thermofisher.com

--
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

AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Peter Hunkeler]

>What are the full contents of the 128-bit PSW? What's the 64-bit TEA value?


I got a CEEDUMP and an analysis from StartTool DA. Both tell me the failing PSW 
is478D0400 A31A7BB8 Looking at the SVC dump at the PRB/XSB which is now 
producing the SVC dump (WLIC is 00020033), I see:
XSB+00E0  PSW16 47850400  8000    231A7BB8

Seems to match.

Unfortunately, there is no LOGREC entry in the dump for this error, the system 
trace table has not been dumped (Grrr...), and there is no SDWA in the dump. 
I'm lost how to find the TEA in this case.

--Peter Hunkeler


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

Re: OS ENQ from COBOL

[Victor Gil]

There is a weird way to embed subroutines in machine instructions right into 
Cobol code by:

a) defining them [fully assembled] as a WORKING-STORAGE literal
b) setting address of a PROCEDURE-POINTER to address of that literal
c) calling the PROCEDURE-POINTER

And no, I don't recommend you actually use this approach, unless really 
desperate.

-Victor-  


Hello Listers,

First off, does anyone know of an IBM COBOL related list? If so, could you 
point me in that direction.

Now, to my question.

I can code an assembler solution, or even a hybrid COBOL/Assembler solution, 
but what I would truly love would be a COBOL only solution.
My need is to be able to determine if a QNAME/RNAME combination is held by 
another address space in the system.
Stated another way, is there any way to use an "ENQ 
(QNAME,RNAME,S,SYSTEM),REQ=TEST" from a COBOL program using COBOL only 
procedural statements?

As I said, I can code an assembler program to issue the ENQ, but because I may 
not always be the one supporting the code, I need to keep it in a language most 
of our shop knows.

In another direction, is there an LE service routine that could issue the ENQ 
TEST?

Thanks to All,
Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | 
www.thermofisher.com

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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Ed Jaffe]

On 7/22/2016 6:50 AM, Peter Hunkeler wrote:

Any hint what I'm missing?


What are the full contents of the 128-bit PSW? What's the 64-bit TEA value?

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Bob Rutledge]

What is the Translation Exception Address?

Bob

On 7/22/2016 10:21 AM, Peter Hunkeler wrote:

 The storage R7 point to, and the storage at offset x'90' is in SP251 key 8. It 
is part of a load module. The fullword at R7+x'90' is the value seen in the 
PSW, so both the L as well as the BASSM have been executed. The program fails 
when the CP is accessing the instruction at the PSW's NSI. The storage at this 
address is a couple of x'00', and the storage is in SP1, key 8.
If anyting was allocated but not accessible, a S0C4-4 would occur, not an 
S0C4-11.
--Peter Hunkeler


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: 22 July, 2016 15:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4-11 abend caused by BASSM to address with all X'00' bytes

I'm confused. Can I not see the obvious?


We've got an S0C4-11 abend in a batch job. The last instructions seem to be

L R15,x'90'(,7)
BASSM R14,R15

R15 has the address that is seen in the PSW in the dump. The storage at this 
address *is* in the dump, and it contains a couple of X'00'.


How can the storage be in the dump when the abend code suggests it is not even 
getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by 
X'' at the PSW NSI address)?


The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in 
SP 1, key 8.


Any hint what I'm missing?


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

Re: System symbols in batch JCL

[Ed Jaffe]

On 7/22/2016 6:06 AM, Tom Marchant wrote:


Or, if you use SDSF, go to the JC panel. All of the JOBCLASS attributes are 
shown for all job classes in a tabular format. Scroll until you find the SysSym 
column. Or use the Locate command:

L SysSym

I suspect (E)JES has similar support, but don't know how to access it.


'CL' command (or 'JC' alias) followed by 'LC SYSSYM'

(E)JES uses 'LC' for locating columns because 'L' is used for locating 
rows just like in other areas of ISPF.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Tom Marchant]

On Fri, 22 Jul 2016 16:21:46 +0200, Peter Hunkeler  wrote:

> The storage R7 point to, and the storage at offset x'90' is in SP251 key 8. 
> It is part of a load module. The fullword at R7+x'90' is the value seen in 
> the PSW, so both the L as well as the BASSM have been executed. The program 
> fails when the CP is accessing the instruction at the PSW's NSI. The storage 
> at this address is a couple of x'00', and the storage is in SP1, key 8.

If you show the exact information from the dump, rather than your 
interpretation of that data, there is a better chance that someone will be able 
to see something that you didn't.

-- 
Tom Marchant

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

Re: DEVTYPE INFO=DASD

[Bill Godfrey]

The result I get from the same DEVTYPE macro is:

FFF0 000F F000 01000800

which differs from the OP in that there are 2 more bytes at the beginning in my 
case.

My results have a fullword for the number of cylinders and a fullword for 
tracks per cylinder, which agrees with all of these manuals:

z/OS 1.10
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2S350/7.2.1.5

z/OS 1.13
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2S380/7.2.1.5

z/OS 2.1 (page 272)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/download/DGT3S300.pdf

I think the OP is just looking at the wrong address, 2 bytes beyond the correct 
address.

Bill
On Fri, 22 Jul 2016 10:01:32 -0400, John Eells wrote:

>I sent in an RCF this morning with what I thought the book should say,
>and copied the lead DADSM/CVAF developer (to make sure my correction
>does not inject some different problem!).
>
>Bill Godfrey wrote:
>> I think the possibility should be considered that the OP may have mistakenly 
>> been looking at the 16 bytes at AREA+2, not AREA. If that happened, and the 
>> missing bytes are hex , the results would be correct for a device with 
>> 65520 cylinders.
>>
>> Bill
>>
>> On Thu, 21 Jul 2016 14:30:41 -0500, Mike Schwab wrote:
>>
   Volume Data
   Tracks . :  982,800
>>>
>>> / 15 = 65,520 = X'FFF0'
>>>
>>> On Thu, Jul 21, 2016 at 2:17 PM, Campbell Jay  
>>> wrote:
 Agree with John.
 Doc should say first halfword of bytes 0 - 3  &  4 - 7.

 MJI2 e . : IM404A
 Command ===>

 Unit . . : 3390

   Volume Data VTOC Data  Free Space   
 TracksCyls
   Tracks . :  982,800 Tracks  . :   360   Size  . . :  
269,730  17,974
   %Used  . :   72   %Used . . : 1Largest . :   
  67,950   4,530
   Trks/Cyls:   15Free DSCBS:17,892  Free

   Extents . :  36

 Disclaimer: No idea what he's working on

 Jay Campbell
 IBM OS Support Section

>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu]
> On Behalf Of John Eells
> Sent: Thursday, July 21, 2016 2:35 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: DEVTYPE INFO=DASD
>
> I think I understand your confusion.  I'm not sure why you're using the 
> z/OS V1.10 level of the book.  But in any event, the current (V2.2) level 
> of the book says this returns, for INFO=DASD:
>
> Returns 16 bytes as follows:
> Bytes 0-3 - Number of cylinders on the device, excluding alternates.
> 
>
> Bytes 4-7 - Number of tracks per cylinder.
>
> So one would reasonably expect x'FFF0' to be the number of cylinders, 
> and x'000FF000' to be the number of tracks per cylinder.  The values of 
> the first halfwords in each word, however, seem far more reasonable 
> (possible, even!).  The correct number of tracks/cylinder is definitely 
> 15.
>
> But what is the actual size of the volume?  You can use "V" on ISPF
> OPT3.4 to see VTOC information, including the volume size in tracks under 
> "Volume data" on the left.  Divide by 15 to get cylinders.  What do you 
> see?
>
> It's likely RCF time...
>
>
>--
>John Eells
>IBM Poughkeepsie
>ee...@us.ibm.com
>
>--
>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

AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Peter Hunkeler]

 The storage R7 point to, and the storage at offset x'90' is in SP251 key 8. It 
is part of a load module. The fullword at R7+x'90' is the value seen in the 
PSW, so both the L as well as the BASSM have been executed. The program fails 
when the CP is accessing the instruction at the PSW's NSI. The storage at this 
address is a couple of x'00', and the storage is in SP1, key 8.
If anyting was allocated but not accessible, a S0C4-4 would occur, not an 
S0C4-11.
--Peter Hunkeler


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: 22 July, 2016 15:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4-11 abend caused by BASSM to address with all X'00' bytes

I'm confused. Can I not see the obvious?


We've got an S0C4-11 abend in a batch job. The last instructions seem to be 

L R15,x'90'(,7)
BASSM R14,R15

R15 has the address that is seen in the PSW in the dump. The storage at this 
address *is* in the dump, and it contains a couple of X'00'.


How can the storage be in the dump when the abend code suggests it is not even 
getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by 
X'' at the PSW NSI address)?


The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in 
SP 1, key 8.


Any hint what I'm missing?







--
Peter Hunkeler

--
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: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Vernooij, CP (ITOPT1) - KLM]

Don't you have the 0C4 on the L instruction? Is the storage at x'90'(,7) 
available?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: 22 July, 2016 15:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4-11 abend caused by BASSM to address with all X'00' bytes

I'm confused. Can I not see the obvious?


We've got an S0C4-11 abend in a batch job. The last instructions seem to be 

L R15,x'90'(,7)
BASSM R14,R15

R15 has the address that is seen in the PSW in the dump. The storage at this 
address *is* in the dump, and it contains a couple of X'00'. 


How can the storage be in the dump when the abend code suggests it is not even 
getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by 
X'' at the PSW NSI address)?


The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in 
SP 1, key 8.


Any hint what I'm missing?







--
Peter Hunkeler

--
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: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Vernooij, CP (ITOPT1) - KLM]

No? What does a wild branch to unavailable storage do then?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: 22 July, 2016 16:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

We just had a discussion: a branch never S0C4's (short version).

Is the storage x'90'(,R7) fetchable?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Friday, July 22, 2016 6:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4-11 abend caused by BASSM to address with all X'00' bytes

I'm confused. Can I not see the obvious?


We've got an S0C4-11 abend in a batch job. The last instructions seem to be 

L R15,x'90'(,7)
BASSM R14,R15

R15 has the address that is seen in the PSW in the dump. The storage at this
address *is* in the dump, and it contains a couple of X'00'. 


How can the storage be in the dump when the abend code suggests it is not
even getmained (S0C4-11)? Why is this not an S0C1 (operation exception
caused by X'' at the PSW NSI address)?

--
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: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Charles Mills]

We just had a discussion: a branch never S0C4's (short version).

Is the storage x'90'(,R7) fetchable?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Friday, July 22, 2016 6:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0C4-11 abend caused by BASSM to address with all X'00' bytes

I'm confused. Can I not see the obvious?


We've got an S0C4-11 abend in a batch job. The last instructions seem to be 

L R15,x'90'(,7)
BASSM R14,R15

R15 has the address that is seen in the PSW in the dump. The storage at this
address *is* in the dump, and it contains a couple of X'00'. 


How can the storage be in the dump when the abend code suggests it is not
even getmained (S0C4-11)? Why is this not an S0C1 (operation exception
caused by X'' at the PSW NSI address)?

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

Re: DEVTYPE INFO=DASD

[John Eells]

I sent in an RCF this morning with what I thought the book should say, 
and copied the lead DADSM/CVAF developer (to make sure my correction 
does not inject some different problem!).


Bill Godfrey wrote:

I think the possibility should be considered that the OP may have mistakenly 
been looking at the 16 bytes at AREA+2, not AREA. If that happened, and the 
missing bytes are hex , the results would be correct for a device with 
65520 cylinders.

Bill

On Thu, 21 Jul 2016 14:30:41 -0500, Mike Schwab wrote:


  Volume Data
  Tracks . :  982,800


/ 15 = 65,520 = X'FFF0'

On Thu, Jul 21, 2016 at 2:17 PM, Campbell Jay  wrote:

Agree with John.
Doc should say first halfword of bytes 0 - 3  &  4 - 7.

MJI2 e . : IM404A
Command ===>

Unit . . : 3390

  Volume Data VTOC Data  Free Space   Tracks
Cyls
  Tracks . :  982,800 Tracks  . :   360   Size  . . : 
269,730  17,974
  %Used  . :   72   %Used . . : 1Largest . :
67,950   4,530
  Trks/Cyls:   15Free DSCBS:17,892  Free

 Extents . :  36

Disclaimer: No idea what he's working on

Jay Campbell
IBM OS Support Section




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu]
On Behalf Of John Eells
Sent: Thursday, July 21, 2016 2:35 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: DEVTYPE INFO=DASD

I think I understand your confusion.  I'm not sure why you're using the z/OS 
V1.10 level of the book.  But in any event, the current (V2.2) level of the 
book says this returns, for INFO=DASD:

Returns 16 bytes as follows:
Bytes 0-3 - Number of cylinders on the device, excluding alternates.


Bytes 4-7 - Number of tracks per cylinder.

So one would reasonably expect x'FFF0' to be the number of cylinders, and 
x'000FF000' to be the number of tracks per cylinder.  The values of the first 
halfwords in each word, however, seem far more reasonable (possible, even!).  
The correct number of tracks/cylinder is definitely 15.

But what is the actual size of the volume?  You can use "V" on ISPF
OPT3.4 to see VTOC information, including the volume size in tracks under "Volume 
data" on the left.  Divide by 15 to get cylinders.  What do you see?

It's likely RCF time...



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: AW: Re: Interface to query length of storage allocated with CEEGTST LE service

[Victor Gil]

I am guessing the length may be stored somewhere in the vicinity of the area 
top address, say within 8-16 bytes ABOVE it.

At least this is how CICS handles GETMAIN requests which also don't require 
length on the FREEMAINs.

Of course, if the convention is not documented it may change at any time ...

-Victor-

=
> I very much doubt it.


Yeah, me too. But I thought I might be missing something and better ask. 


>I'm curious; what will you do with this info if it is available? 
 

I'm asking because I have been asked by our middle war guys. Our applications 
are required to use our own middle ware service routines for certain functions 
instead of HLL or LE or CICS services directly. (This is not part of the 
discussion.)


They wanted to know if there is a possibility to retrieve the length somehow 
instead of remembering it somewhere in own data structures. (I don't know more 
details about the why and what for.)


Thanks for the hint regarding LE possibly rounding up. Since I do not know 
details what they intend to do, I cannot say if this rouding is important for 
them. But I'll pass it on.




Thanks


-- 
Peter Hunkeler

 


--
Peter Hunkeler 

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

S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Peter Hunkeler]

I'm confused. Can I not see the obvious?


We've got an S0C4-11 abend in a batch job. The last instructions seem to be

L R15,x'90'(,7)
BASSM R14,R15

R15 has the address that is seen in the PSW in the dump. The storage at this 
address *is* in the dump, and it contains a couple of X'00'.


How can the storage be in the dump when the abend code suggests it is not even 
getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by 
X'' at the PSW NSI address)?


The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in 
SP 1, key 8.


Any hint what I'm missing?







--
Peter Hunkeler

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

Re: System symbols in batch JCL

[Tom Marchant]

On Thu, 21 Jul 2016 15:59:24 -0500, John McKown wrote:

>$DJOBDEF(A)
>
>And then look for SYSSYM in the SYSLOG output.​

Or, if you use SDSF, go to the JC panel. All of the JOBCLASS attributes are 
shown for all job classes in a tabular format. Scroll until you find the SysSym 
column. Or use the Locate command:

L SysSym

I suspect (E)JES has similar support, but don't know how to access it.

-- 
Tom Marchant

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

Re: Resource Group Limits as a cost containment method?

[Scott Chapman]

Yes, resource groups might be able to help if you don't want to lower the DC 
itself. But it's very dependent on the situation. My impression from your 
discussion is that addressing the scheduling issues may be the best first step 
though.

Remember that it's an average over 4 hours. So if you're running at 100% for 
two hours and then 50% for the next two hours, smearing the work out so it runs 
more evenly at 75% for 4 hours doesn't change that 4 hour average. Well, at 
least from the MLC perspective. But you mention a chargeback system so I'm not 
sure whether lowering the R4HA is the goal or something else to lower a 
chargeback number is really the goal. 

If the end goal is to lower the actual amount owed IBM, don't forget that a 10% 
reduction in the R4HA almost always equates to something less than a 10% cost 
reduction. And understand your ELA Ts  if you have one.

Scott


On Thu, 21 Jul 2016 09:59:10 -0500, Tim Hare  
wrote:

>There's a system where their 4-hour rolling average maximum is always during 
>their batch window, when they routinely reach their defined capacity limit,  
>which in turn affects what they pay in a chargeback system.
>
>Because of scheduling dumbness (another story) they have several gaps in their 
>batch window where nothing runs, giving some leeway for jobs to increase their 
>elapsed time - not the usual thing you want to do, but bear with us.
>
>Would it be worth investigating setting a resource group limit for the batch 
>service class(es) to hold the total 4HRA down as a cost-saving measure, or are 
>resource group limits going to cause more trouble than they are worth?
>
>--
>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

AW: Re: AW: Re: Setting dump options for SVC dumps taken by StarTool DA-Batch?

[Peter Hunkeler]

>If they specify the SDATA NODEFAULTS option, that would cause
>the options added by IEACMD00 to be ignored.




I've displayed the flags again:
- "Ignore CHNGDUMP parameters" was set in SDUFLAG1
- "NODEFAULTS" was set in SDUSDAT3


Sigh.


VERBX IEAVTSFS tells me partil dump reason codes are all zeroes.

So I'm left with the hope that SmartRestart or StarTool DA (whichever schedules 
the dump) can be told to include the trace table in the dump request.


--
Peter Hunkeler

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

Re: Resource Group Limits as a cost containment method?

[Vernooij, CP (ITOPT1) - KLM]

Sure, if you want to avoid capping, RG's are the method to limit hungry 
workloads.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: 22 July, 2016 9:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: Resource Group Limits as a cost containment method?

 
>I am not quite sure what you are aiming at.  




Speaking for our environment and our paint points, only. It is true that the 
cost is under conrtol with Defined Capacity or Group Capacity Limit set. The 
problem is the huge amount of capacity that you might loose once your system is 
capping. If this happend during the batch window, that's under control and not 
really an issue. 


However, the online workload does not cope well with capping, this is the 
period we want to avoid capping as best as we can.


Proper Service Class make sure important work gets resources first. But if 
there is no online such as during the batch window, batch takes it all and 
thereby is driving the R4HA towards the Defined Capacits or Group Capacity 
limits, leaving no spare for the online window. 


Service Classes cannot limit resource access when spare resources are 
available. Resource Groups can, this is what they have been invented for.


So at critical times such as month ends, we're limiting what batch can take, 
effectively a kind of capping within a z/OS instance but only for certain types 
of workload, i.e. batch.


--
Peter Hunkeler





--
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

AW: Re: Resource Group Limits as a cost containment method?

[Peter Hunkeler]

>I am not quite sure what you are aiming at.




Speaking for our environment and our paint points, only. It is true that the 
cost is under conrtol with Defined Capacity or Group Capacity Limit set. The 
problem is the huge amount of capacity that you might loose once your system is 
capping. If this happend during the batch window, that's under control and not 
really an issue.


However, the online workload does not cope well with capping, this is the 
period we want to avoid capping as best as we can.


Proper Service Class make sure important work gets resources first. But if 
there is no online such as during the batch window, batch takes it all and 
thereby is driving the R4HA towards the Defined Capacits or Group Capacity 
limits, leaving no spare for the online window.


Service Classes cannot limit resource access when spare resources are 
available. Resource Groups can, this is what they have been invented for.


So at critical times such as month ends, we're limiting what batch can take, 
effectively a kind of capping within a z/OS instance but only for certain types 
of workload, i.e. batch.


--
Peter Hunkeler





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

Re: System symbols in batch JCL

[Paul Gilmartin]

On Thu, 21 Jul 2016 22:32:39 -0700, Ed Jaffe wrote:

>On 7/21/2016 10:05 PM, Ed Jaffe wrote:
>> I gotta ask, how on earth have you guys survived all these years
>> without  system symbols support enabled in JES?
>
>Never mind. I answered my own question.
>
>It's been only three years since this support became generally available
>in JES2.
> 
Prior to that, was it only for JES3?  What's the default setting?

Mainframe security has long been based on "Need to Know".
Our admin is fairly compliant: "Yes" is often a sufficient answer
to "Need to know?"

And we like to test our products in a most restrictive system
comfiguration.  Testing requirements increas exponentially
with the number of configurable system options.

And remember how few years ago a FAQ in these fora was, "How
can we prevent our programmers' using OS/390 UNIX System
Services if they can't attest to a need?"

Still, I'm glad that there is no RACF class to (DIS)ALLOW use of
(the similar) UNIX environment variables -- generally I share
your perplexity.

>Prior to that, it was available to started tasks only.

-- gil

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

Re: Resource Group Limits as a cost containment method?

[Vernooij, CP (ITOPT1) - KLM]

I am not quite sure what you are aiming at. 

You say the system hits its defined capacity, so the costs are fully under 
control by the DC, aren't they?

If you want to lower costs, the way is to lower the DC. If you expect 
performance problems, you can set different goals for different batch: give the 
important batch that must run at that moment a high Importance and give the 
batch that runs there because of scheduling dumbness but which does not need 
good performance then, a lower Importance.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tim Hare
Sent: 21 July, 2016 16:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Resource Group Limits as a cost containment method?

There's a system where their 4-hour rolling average maximum is always during 
their batch window, when they routinely reach their defined capacity limit,  
which in turn affects what they pay in a chargeback system.

Because of scheduling dumbness (another story) they have several gaps in their 
batch window where nothing runs, giving some leeway for jobs to increase their 
elapsed time - not the usual thing you want to do, but bear with us.

Would it be worth investigating setting a resource group limit for the batch 
service class(es) to hold the total 4HRA down as a cost-saving measure, or are 
resource group limits going to cause more trouble than they are worth?

--
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