Re: System symbols in batch JCL

[Edward Finnell]

Well some of us old timers wrote CLISTs to put in symbols and submit  to 
intrdr. Then in 80's we got File Tailoring with ISPF.
 
 
In a message dated 7/22/2016 12:32:46 A.M. Central Daylight Time,  
edja...@phoenixsoftware.com writes:

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


--
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/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, it was available to started tasks only.

--
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: System symbols in batch JCL

[Peter Hunkeler]

>I gotta ask, how on earth have you guys survived all these years
>without  system symbols support enabled in JES?



For production jobs, I guess the schedulers jumped in. They long (always?) 
supported symbols that will be resolver at submit time. A couple of date/time 
symbols and even better date time functions help even more. And they long 
(always?) supported these symbols in instream data (DD *).
For those jobs I doubt anyone has any need for the system symbol support 
introduced with z/OS V2.1


Peronal jobs are a different story. It has always been a great pita that there 
was no system symbol support for batch jobs, and for batch and STC, that there 
was no support for system and JCL symbols in instream data.


I personaly have quickly started to use instream support, and to a lesser 
extent, system symbols in my own jobs.


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

[Ed Jaffe]

On 7/21/2016 5:27 PM, Jesse 1 Robinson wrote:

In my successful tests, however, it's not clear what class I was running in 
because of WLM. I enabled only CLASS A for SYSSYM.

ICH70001I TSOSKIP   LAST ACCESS AT 17:13:07 ON THURSDAY, JULY 21, 2016
$HASP373 TIMETEST STARTED - WLM INIT  - SRVCLASS BATCHS   - SYS X0
SCEUJI02I JOB  TIMETEST STARTED17.13.08 21 JUL 16
IEF403I TIMETEST - STARTED - TIME=17.13.07
SCEACT01I STEP TIMETEST TIMETEST   CPU 00:00:00.00 CC=

In fact, there is an installation (local) message which indicates that the job 
did not run in CLASS A:  'CLASS SET TO C'. So how did it work?


All that matters is the JES job class at JCL conversion time.

I gotta ask, how on earth have you guys survived all these years 
without  system symbols support enabled in JES? That's like going on a 
trip to ancient times with Mr. Peabody in the Way-Back machine!


Is this just a sandbox? Or is it a real system with real users?

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

[Edward Finnell]

I would guess the CI accepted it as CLASS=A and  did the requisite  
substitution and wrote it to SPOOL to be executed. From there WLM and Exits  
provided a CLASS to run.
 
 
In a message dated 7/21/2016 7:28:40 P.M. Central Daylight Time,  
jesse1.robin...@sce.com writes:

In fact,  there is an installation (local) message which indicates that the 
job did not  run in CLASS A:  'CLASS SET TO C'. So how did it work?  



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

Good use of COBOL EXIT SECTION?

[Bill Woodger]

A good idea, but why impose the extra paragraph-name per SECTION?

procedure division.
main section.
mainline.
perform one
perform two
goback
.

one section.
[...do something...]
exit section
.

two section.
   [...do something else...]
exit section
.

You don't need the EXIT SECTION in the "MAIN SECTION", because MAIN is never 
PERFORMed, adding a paragraph doesn't mess anything (as long as EXIT PARAGRAPH 
isn't in there...).

Adding paragraph-names to SECTIONs is just an invitation for the next person 
along to use GO TO if they feel like it, and they are not needed to make the 
protection work.

It's a good idea. 

Of course, if the SECTION has other labels, nothing to stop someone doing the 
other thing, which is including it accidentally "within" a SECTION rather than 
appended to it. If they are SECTIONs without labels, you could make them all 
paragraphs, anyway (with no need for "exit paragraph" unless you want to 
protect against someone appending a bunch of code into a paragraph by 
accident... going too far).

I don't think an RFE stands a chance. How would you compile existing code?

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

Thanks to everyone. I indicated in my original post that I had turned on SYSSYM 
for Class A, but I was using obsolete system symbols. Duh. It was simple after 
all. 

In my successful tests, however, it's not clear what class I was running in 
because of WLM. I enabled only CLASS A for SYSSYM. 

ICH70001I TSOSKIP   LAST ACCESS AT 17:13:07 ON THURSDAY, JULY 21, 2016
$HASP373 TIMETEST STARTED - WLM INIT  - SRVCLASS BATCHS   - SYS X0   
SCEUJI02I JOB  TIMETEST STARTED17.13.08 21 JUL 16
IEF403I TIMETEST - STARTED - TIME=17.13.07   
SCEACT01I STEP TIMETEST TIMETEST   CPU 00:00:00.00 CC=   

In fact, there is an installation (local) message which indicates that the job 
did not run in CLASS A:  'CLASS SET TO C'. So how did it work? 


.
.
.
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 Paul Gilmartin
Sent: Thursday, July 21, 2016 4:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: System symbols in batch JCL

On 2016-07-21 15:20, Cieri, Anthony wrote:
> 
>   Try   $D JOBCLASS(*),SYSSYM 
> 
Thanks.  That shows me that all job classes at my site have DISALLOW.

But that works only because I have operator privilege.  Let me ask the question 
on behalf of a hypothetical programmer who hasn't such privilege.  I suppose 
that programmer can simply call the system administrator and hope not to get 
the BOFH.

And, further, I ask myself, Why must the facility be controlled?
And I answer myself with a couple possible reasons:

o Some system symbols might have sensitive values (passwords?
  the CIO's personal phone number?) which must be concealed.

o Some dusty decks may contain "//SYSUT2 DD DISP=(,PASS),DSN="
  and for compatibility may continue to run in classes with
  SYSSYM=DISALLOW.

I have long felt that reference in JCL to an undefined apparent symbol should 
always have been treated as a syntax error.  That compatibility argument 
reinforces my sentiment.

-- gil


--
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 2016-07-21 15:20, Cieri, Anthony wrote:
> 
>   Try   $D JOBCLASS(*),SYSSYM 
> 
Thanks.  That shows me that all job classes at my site have DISALLOW.

But that works only because I have operator privilege.  Let me ask
the question on behalf of a hypothetical programmer who hasn't
such privilege.  I suppose that programmer can simply call the
system administrator and hope not to get the BOFH.

And, further, I ask myself, Why must the facility be controlled?
And I answer myself with a couple possible reasons:

o Some system symbols might have sensitive values (passwords?
  the CIO's personal phone number?) which must be concealed.

o Some dusty decks may contain "//SYSUT2 DD DISP=(,PASS),DSN="
  and for compatibility may continue to run in classes with
  SYSSYM=DISALLOW.

I have long felt that reference in JCL to an undefined apparent
symbol should always have been treated as a syntax error.  That
compatibility argument reinforces my sentiment.

-- gil

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

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 Reichman Joseph
>> Sent: Thursday, July 21, 2016 3:09 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: DEVTYPE INFO=DASD
>>
>> I just got word from Jay Campbell that the device capability is 17,974 cyls 
>> I am getting back X'FFF0'  or 65,520, Since he is in touch with IBM I would 
>> suggest you contact him
>>
>> Thanks
>>
>> Joe Reichman
>> Joe Reichman
>>
>> IT Specialist
>> Master Files Division
>> New Carrollton Federal Building, B7-182
>> OS:CTO:AD:CP:I:IB
>> Flex M,T,Th,F
>> Home office (240) 863 - 3965
>> Office (240) 613-4350
>> Cell (917) 748-9693
>> TOD M - F  7:30 am  - 4:00 pm
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On 
>> Behalf Of John Eells
>> Sent: Thursday, July 21, 2016 2:42 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: DEVTYPE INFO=DASD
>>
>> Well, yes, but we should get the book right.  So do you mind telling me what 
>> the actual volume size is, just to confirm?
>>
>> Reichman Joseph wrote:
>>> It is the first half word of each has to be
>>>
>>> Joe Reichman
>>> Joe Reichman
>>>
>>> IT Specialist
>>> Master Files Division
>>> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex
>>> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
>>> Cell (917) 748-9693
>>> TOD M - F  7:30 am  - 4:00 pm
>>>
>>>
>>> -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...
>>>
>>>
>>> Reichman Joseph wrote:
 7.2.15 Marked DEVTYPE-  info form   from DFSMSdfp "Advanced Services"  
 z/os V1R10.0

 Joe Reichman
 Joe Reichman

 IT Specialist
 Master Files Division
 New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex
 M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
 Cell (917) 748-9693
 TOD M - F  7:30 am  - 4:00 pm


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

 Reichman Joseph wrote:

> The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and
> bytes 4 - 7 000FF000 is tracks per cyl ? am I misreading
> misunderstanding the documentation

 What docs? Could you be kind to give us the URL of that source of above 
 info and docs?

> I was looking for the capability on a dasd device DEVTYPE
> (R6),(AREA,L'AREA),INFOLIST=ILIST2
> ILIST2   DEVTYPE INFO=DASD
> AREA DSXL16

Re: System symbols in batch JCL

[Roger Lowe]

Skip,
  The following jcl should do the trick - 

//ZZZSKIP  JOB (ZZZ,1234),'TEST',  
// MSGCLASS=2,CLASS=M,NOTIFY=,  
// MSGLEVEL=(1,1),TIME=1440,   
// REGION=0M   
//*
//SYMBOLS  EXPORT SYMLIST=*
//*
//D1   SET D= 
//T1   SET T= 
//*
//TIMETEST EXEC PGM=IKJEFT01   
//SYSTSPRT DD DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,   
//UNIT=SYSALLDA,   
//DSN=ZZZ.SKIP.REPORT.D 
//SYSTSIN  DD DUMMY

Hope it helps. Roger


On Thu, 21 Jul 2016 19:53:44 +, Jesse 1 Robinson  
wrote:

>I'm trying to use system symbols in batch JCL under z/OS 2.1. Specifically, 
>I'd like to create a DSN like this:
>
>   TSOSKIP.REPORT.D-local-date.T-local-time
>
>I've perused KC but still cannot get to work. Now maybe DSN simply does not 
>allow embedded symbolics, but I did not see that prohibition. Here's what I 
>get.
>
>3 // SET D=
>4 // SET T=
>  //*
>5 //TIMETEST EXEC PGM=IKJEFT01
>6 //SYSTSIN  DD *
>7 //SYSTSPRT DD DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,
>  //UNIT=SYSALLDA,
>  //DSN= TSOSKIP.REPORT.D
>  IEFC653I SUBSTITUTION JCL - 
> DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,UNIT=SYSALLDA,
>  DSN= TSOSKIP.REPORT.D
>. MESSAGE
>7 IEFC627I INCORRECT USE OF AMPERSAND IN THE DSN FIELD
>
>I read that system symbols must be enabled by class, which I did for class A: 
>$HASP837 JOBCLASS(A) SYSSYM=ALLOW
>
>But it looks like my job is failing at conversion and never getting to 
>execution. Shouldn't this be easy? ;-)
>
>.
>.
>.
>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
>
>
>--
>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

Good use of COBOL EXIT SECTION?

[Frank Swarbrick]

I'm also going to post this in the IBM COBOL Cafe, but I'm not sure how many 
people actually use that site...

So as you might know, I'm interested/excited about the new "EXIT" statements in 
Enterprise COBOL.  I just had a thought on a good use of EXIT SECTION.

We too often run in to issues where a developer will add a new paragraph for a 
new process, and they will add it so that positionally it becomes part of a 
SECTION within the procedure division, and this it is unintentionally performed 
as the result of a PERFORM of that section.

For example, take this following simple code:

procedure division.
main section.
mainline.
perform one
perform two
goback.

one section.
[...do something...]

two section.
   [...do something else...]

Let's say that a new developer wants to add a third process.  They add the 
following to the end of the program:

three.
[...do a third thing...]

They then add "perform three" after "perform two" in the "mainline" paragraph.  
So what happens?  The code within paragraph "three" gets executed twice; the 
first time as part of "perform two", because "three" is part of the section 
named "two", and then again as a result of the new "perform three".

Now in this example it would probably become obvious during testing that this 
is occurring, so hopefully (!!) it would not make it to production.  But some 
times the "perform two" may only occur in certain edge cases, and so the 
unintentional execution of "three" might not occur during the testing phases.

So many will agree that procedure division sections are a bad idea.  Well 
that's a fine opinion, and one I can get behind.  But the fact is, they exist 
in many programs, and to often they have this sort of bug.  So what to do?

I had a thought that using an explicit "EXIT SECTION" to the end of all 
procedure division sections would be a good first start.  In the above example 
there could be a "one-exit" paragraph at the end of "one section" that contains 
just the "exit section" statement.  And a "two-exit" paragraph at the end of 
"two section" that did the same.

By doing this you have a "defense" against someone doing what happened here.  
Now even if "three" is unintentionally made part of "two section" we will no 
longer "drop through" to it.  The EXIT SECTION (unlike the fairly useless 
legacy EXIT statement, which is a NO-OP) will cause the flow to branch around 
"three" (and anything following "three") to the "true" end of the section.

Of course there is nothing to enforce this standard.  But perhaps there could 
be!  I'm thinking of an RFE to add a compiler option that would require all 
sections to be terminated by a paragraph consisting of only the EXIT SECTION 
statement.  Could that catch all of these types of bugs?  I'm thinking it 
could.  Take the example above, with this new rule in force:

procedure division.
main section.
mainline.
perform one
perform two
goback.

exit-mainline.
exit section.

one section.
[...do something...]

exit-one.
exit section.

two section.
   [...do something else...]

exit-two.
exit section.

Now if someone adds something after exit-two it will violate the rule and give 
a warning, or even an error.  The developer would fix it by adding "three 
section" instead of "three", as well as its own "exit-section" paragraph with 
the "exit section" statement.

Obviously pretty much every existing COBOL program that uses procedure division 
sections would violate the rule.  But perhaps there could be a simple 
"migration tool" that could update source code to conform to the rule.  A more 
advanced migration tool might even look for existing "exit-section" paragraphs 
with just the "EXIT", which is truly how statement procedure division sections 
currently should be "terminated", and if there is not a SECTION (or end of 
source) following it, report an error.  This assumes all sections are 
terminated this way, which I'm sure is not the case, but it still seems 
worthwhile.

Make any sense?  I'm sure Bill W will have something to say about it!

Frank


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

Re: Real purpose of hipersocket

[R.S.]

W dniu 2016-07-21 o 16:54, Tim Hare pisze:
[...]

You can test the difference in speed -  find a large dataset (or create one),  
and FTP it using the OSA network and the other system's non-hipersocket IP 
address,  then FTP the same file using the hipersocket IP address.


Actually I did it. AFAIK it was on z990 machine (or z9) with 1000BaseT 
OSA card.
FTP transfer between LPARs was equally fast when using OSA and 
Hipersockets. Reason: dasd is to slow to feel the difference. I had to 
use memory to memory data transfer to observe the elapsed time difference.
I haveb't tested it but I strongly believe the difference between 
Hipersockets and OSA 10GbE will be even smaller.


Caution: I'm talking about single big file, single session, etc. In case 
of many small sessions thing may look different.


--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: IBM Z/os Explorer and CICS Explorer

[Ward, Mike S]

You didn't have to accept the licensing agreement. If I remember correctly it 
said something after the trial period they would consider it an IPLA product.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barkow, Eileen
Sent: Thursday, July 21, 2016 2:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM Z/os Explorer and CICS Explorer

I just installed the latest AQUA verion of  both explorers and could not get 
anywhere with installation manager. just download the zip file.
There was nothing about having to purchase anything.

The real fun was trying to install the features into it. the  HELP  'INSTALL 
NEW SOFTWARE' option pointed to a web site which did not let you download from.
 I finally found a humongous zip file that took all day to download but had the 
features in it.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ward, Mike S
Sent: Thursday, July 21, 2016 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Z/os Explorer and CICS Explorer

I wonder if someone from IBM that's monitoring this list can help.

I thought if you had a licensed copy of z/OS and CICS you could use the z/OS 
explorer and the CICS explorer. After using the installation manager to install 
the products it seems to indicate that you have a trial period and then you 
must purchase the products. The IBM site is so confusing I can't seem to find 
information that explains this. Can someone help?

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by replying to this e-mail 
and delete the e-mail from your system.

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

[Cieri, Anthony]

Try   $D JOBCLASS(*),SYSSYM 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, July 21, 2016 4:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: System symbols in batch JCL

On Thu, Jul 21, 2016 at 3:52 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 21 Jul 2016 19:53:44 +, Jesse 1 Robinson wrote:
>
> >I'm trying to use system symbols in batch JCL under z/OS 2.1.
> Specifically, I'd like to create a DSN like this:
> >
> Doesn't work for me, either:
>
>  6 //FOO   DDDISP=SHR,DSN=
>IEFC653I SUBSTITUTION JCL - DISP=SHR,DSN=gil.
>  7 //
>
> >I read that system symbols must be enabled by class, which I did for
> class A: $HASP837 JOBCLASS(A) SYSSYM=ALLOW
> >
> >But it looks like my job is failing at conversion and never getting 
> >to
> execution. Shouldn't this be easy? ;-)
> >
> How can I query that setting?  If simply  were itself a symbol 
> I could use it would be too easy; IBM would never do it that way.
>

​It is dependent on the setting for the __JOB CLASS__ in which the job was 
submitted. In the original, that is JOB CLASS=A. To see if it is enabled (by 
default it is _not_), enter the z/OS operator command:

$DJOBDEF(A)

And then look for SYSSYM in the SYSLOG output.​




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



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

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

[John McKown]

On Thu, Jul 21, 2016 at 3:52 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 21 Jul 2016 19:53:44 +, Jesse 1 Robinson wrote:
>
> >I'm trying to use system symbols in batch JCL under z/OS 2.1.
> Specifically, I'd like to create a DSN like this:
> >
> Doesn't work for me, either:
>
>  6 //FOO   DDDISP=SHR,DSN=
>IEFC653I SUBSTITUTION JCL - DISP=SHR,DSN=gil.
>  7 //
>
> >I read that system symbols must be enabled by class, which I did for
> class A: $HASP837 JOBCLASS(A) SYSSYM=ALLOW
> >
> >But it looks like my job is failing at conversion and never getting to
> execution. Shouldn't this be easy? ;-)
> >
> How can I query that setting?  If simply  were itself a symbol
> I could use it would be too easy; IBM would never do it that way.
>

​It is dependent on the setting for the __JOB CLASS__ in which the job was
submitted. In the original, that is JOB CLASS=A. To see if it is enabled
(by default it is _not_), enter the z/OS operator command:

$DJOBDEF(A)

And then look for SYSSYM in the SYSLOG output.​




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



-- 
"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: System symbols in batch JCL

[Lizette Koehler]

Table 1 describes the dynamic system symbols and the releases for which they are
valid. The names of the following system symbols are changed from previous
releases of MVST:
New symbol  Old symbol
 

 



>From the z/OS V2.2 manual

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieae20
0/dynpsm.htm
Init and Tuning, sharing system symbols

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Thursday, July 21, 2016 12:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: System symbols in batch JCL
> 
> I'm trying to use system symbols in batch JCL under z/OS 2.1. Specifically,
> I'd like to create a DSN like this:
> 
>TSOSKIP.REPORT.D-local-date.T-local-time
> 
> I've perused KC but still cannot get to work. Now maybe DSN simply does not
> allow embedded symbolics, but I did not see that prohibition. Here's what I
> get.
> 
> 3 // SET D=
> 4 // SET T=
>   //*
> 5 //TIMETEST EXEC PGM=IKJEFT01
> 6 //SYSTSIN  DD *
> 7 //SYSTSPRT DD DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,
>   //UNIT=SYSALLDA,
>   //DSN= TSOSKIP.REPORT.D
>   IEFC653I SUBSTITUTION JCL -
> DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,UNIT=SYSALLDA,
>   DSN= TSOSKIP.REPORT.D
> . MESSAGE
> 7 IEFC627I INCORRECT USE OF AMPERSAND IN THE DSN FIELD
> 
> I read that system symbols must be enabled by class, which I did for class A:
> $HASP837 JOBCLASS(A) SYSSYM=ALLOW
> 
> But it looks like my job is failing at conversion and never getting to
> execution. Shouldn't this be easy? ;-)
> 
> .
> .
> .
> 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

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

AW: System symbols in batch JCL

[Peter Hunkeler]

>3 // SET D=


Without verifying exactly with the manual, I seem to remember that it talks 
about old and new date and time symbols.  is an old one and this does not 
work (I don't know if this is documented somewhere).  is a new symbol 
and this one is working with batch JCL.


Try using  and  (I hope I remember the names correctly).


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

[Ed Jaffe]

On 7/21/2016 12:53 PM, Jesse 1 Robinson wrote:

I'm trying to use system symbols in batch JCL under z/OS 2.1. Specifically, I'd 
like to create a DSN like this:

TSOSKIP.REPORT.D-local-date.T-local-time

I've perused KC but still cannot get to work. Now maybe DSN simply does not 
allow embedded symbolics, but I did not see that prohibition. Here's what I get.

3 // SET D=
4 // SET T=
   //*
5 //TIMETEST EXEC PGM=IKJEFT01
6 //SYSTSIN  DD *
7 //SYSTSPRT DD DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,
   //UNIT=SYSALLDA,
   //DSN= TSOSKIP.REPORT.D
   IEFC653I SUBSTITUTION JCL - 
DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,UNIT=SYSALLDA,
   DSN= TSOSKIP.REPORT.D
. MESSAGE
7 IEFC627I INCORRECT USE OF AMPERSAND IN THE DSN FIELD

I read that system symbols must be enabled by class, which I did for class A: 
$HASP837 JOBCLASS(A) SYSSYM=ALLOW


Your problem is simply that you're referencing symbols that don't exist. 
What you want is:


//SKIPTEST JOB 1,JAFFE,CLASS=A,MSGCLASS=T
//TIMETEST EXEC PGM=IKJEFT01
//SYSTSIN  DD *
//SYSTSPRT DD DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,
//UNIT=SYSALLDA,
//DSN=TSOSKIP.REPORT.D

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

RES: EXTERNAL: System symbols in batch JCL

[ITURIEL DO NASCIMENTO NETO]

Look if your jobclass is defined as SYSSYM=ALLOW


Atenciosamente / Regards / Saludos

BANCO BRADESCO S.A.
4250 / DPCD Engenharia de Software
Sistemas Operacionais Mainframes
Ituriel do Nascimento Neto
Tel: +55 11 3684-9602 R: 49602 3-1404
Fax: +55 11 3684-4427



Banco Bradesco.
Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016.

-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de 
Jerry Whitteridge
Enviada em: quinta-feira, 21 de julho de 2016 16:59
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: Re: EXTERNAL: System symbols in batch JCL

Skip - try closing the symbolic with a dot

DSN= TSOSKIP.REPORT.D
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: Thursday, July 21, 2016 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: System symbols in batch JCL

I'm trying to use system symbols in batch JCL under z/OS 2.1. Specifically, I'd 
like to create a DSN like this:

   TSOSKIP.REPORT.D-local-date.T-local-time

I've perused KC but still cannot get to work. Now maybe DSN simply does not 
allow embedded symbolics, but I did not see that prohibition. Here's what I get.

3 // SET D=
4 // SET T=
  //*
5 //TIMETEST EXEC PGM=IKJEFT01
6 //SYSTSIN  DD *
7 //SYSTSPRT DD DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,
  //UNIT=SYSALLDA,
  //DSN= TSOSKIP.REPORT.D
  IEFC653I SUBSTITUTION JCL - 
DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,UNIT=SYSALLDA,
  DSN= TSOSKIP.REPORT.D
. MESSAGE
7 IEFC627I INCORRECT USE OF AMPERSAND IN THE DSN FIELD

I read that system symbols must be enabled by class, which I did for class A: 
$HASP837 JOBCLASS(A) SYSSYM=ALLOW

But it looks like my job is failing at conversion and never getting to 
execution. Shouldn't this be easy? ;-)

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


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

AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICE...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

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

Re: EXTERNAL: System symbols in batch JCL

[Jerry Whitteridge]

Skip - try closing the symbolic with a dot

DSN= TSOSKIP.REPORT.D
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: Thursday, July 21, 2016 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: System symbols in batch JCL

I'm trying to use system symbols in batch JCL under z/OS 2.1. Specifically, I'd 
like to create a DSN like this:

   TSOSKIP.REPORT.D-local-date.T-local-time

I've perused KC but still cannot get to work. Now maybe DSN simply does not 
allow embedded symbolics, but I did not see that prohibition. Here's what I get.

3 // SET D=
4 // SET T=
  //*
5 //TIMETEST EXEC PGM=IKJEFT01
6 //SYSTSIN  DD *
7 //SYSTSPRT DD DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,
  //UNIT=SYSALLDA,
  //DSN= TSOSKIP.REPORT.D
  IEFC653I SUBSTITUTION JCL - 
DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,UNIT=SYSALLDA,
  DSN= TSOSKIP.REPORT.D
. MESSAGE
7 IEFC627I INCORRECT USE OF AMPERSAND IN THE DSN FIELD

I read that system symbols must be enabled by class, which I did for class A: 
$HASP837 JOBCLASS(A) SYSSYM=ALLOW

But it looks like my job is failing at conversion and never getting to 
execution. Shouldn't this be easy? ;-)

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


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

System symbols in batch JCL

[Jesse 1 Robinson]

I'm trying to use system symbols in batch JCL under z/OS 2.1. Specifically, I'd 
like to create a DSN like this:

   TSOSKIP.REPORT.D-local-date.T-local-time

I've perused KC but still cannot get to work. Now maybe DSN simply does not 
allow embedded symbolics, but I did not see that prohibition. Here's what I get.

3 // SET D=
4 // SET T=
  //*
5 //TIMETEST EXEC PGM=IKJEFT01
6 //SYSTSIN  DD *
7 //SYSTSPRT DD DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,
  //UNIT=SYSALLDA,
  //DSN= TSOSKIP.REPORT.D
  IEFC653I SUBSTITUTION JCL - 
DISP=(,CATLG),SPACE=(TRK,1),RECFM=FB,LRECL=80,UNIT=SYSALLDA,
  DSN= TSOSKIP.REPORT.D
. MESSAGE
7 IEFC627I INCORRECT USE OF AMPERSAND IN THE DSN FIELD

I read that system symbols must be enabled by class, which I did for class A: 
$HASP837 JOBCLASS(A) SYSSYM=ALLOW

But it looks like my job is failing at conversion and never getting to 
execution. Shouldn't this be easy? ;-)

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


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

[Mike Schwab]

>  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 Reichman Joseph
> Sent: Thursday, July 21, 2016 3:09 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: DEVTYPE INFO=DASD
>
> I just got word from Jay Campbell that the device capability is 17,974 cyls I 
> am getting back X'FFF0'  or 65,520, Since he is in touch with IBM I would 
> suggest you contact him
>
> Thanks
>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182
> OS:CTO:AD:CP:I:IB
> Flex M,T,Th,F
> Home office (240) 863 - 3965
> Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On 
> Behalf Of John Eells
> Sent: Thursday, July 21, 2016 2:42 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: DEVTYPE INFO=DASD
>
> Well, yes, but we should get the book right.  So do you mind telling me what 
> the actual volume size is, just to confirm?
>
> Reichman Joseph wrote:
>> It is the first half word of each has to be
>>
>> Joe Reichman
>> Joe Reichman
>>
>> IT Specialist
>> Master Files Division
>> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex
>> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
>> Cell (917) 748-9693
>> TOD M - F  7:30 am  - 4:00 pm
>>
>>
>> -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...
>>
>>
>> Reichman Joseph wrote:
>>> 7.2.15 Marked DEVTYPE-  info form   from DFSMSdfp "Advanced Services"  z/os 
>>> V1R10.0
>>>
>>> Joe Reichman
>>> Joe Reichman
>>>
>>> IT Specialist
>>> Master Files Division
>>> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex
>>> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
>>> Cell (917) 748-9693
>>> TOD M - F  7:30 am  - 4:00 pm
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu]
>>> On Behalf Of Elardus Engelbrecht
>>> Sent: Thursday, July 21, 2016 12:52 PM
>>> To: IBM-MAIN@listserv.ua.edu
>>> Subject: Re: DEVTYPE INFO=DASD
>>>
>>> Reichman Joseph wrote:
>>>
 The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and
 bytes 4 - 7 000FF000 is tracks per cyl ? am I misreading
 misunderstanding the documentation
>>>
>>> What docs? Could you be kind to give us the URL of that source of above 
>>> info and docs?
>>>
 I was looking for the capability on a dasd device DEVTYPE
 (R6),(AREA,L'AREA),INFOLIST=ILIST2
 ILIST2   DEVTYPE INFO=DASD
 AREA DSXL16
>>>
>>> Hmmm, interesting application of that useful macro. I must try out
>>> this little gem next week on my z/OS v2.1 sandbox when I'm returning
>>> to my bread and butter work... ;-)
>>>
 This was the data returned in area R15 = 0
 FFF0 000FF000 0100 0800
>>>
>>> On what z/OS level were you trying to try out that Assembler snippet? How 
>>> did you obtained the contents of that R15? Via a dump or a MVC or something 
>>> else?

Re: IBM Z/os Explorer and CICS Explorer

[Barkow, Eileen]

by the way, if you do get either EXPLORER installed, there is a major problem 
when trying to connect to z/os.
It turned out that even though IBM supplies a copy of the JRE in the EXPLORER 
directories,  it contains some security options which yield
some cryptic RSA key error. This happened with the previous release of Explorer 
as well.
It took a while to find this on DeveloperWorks, but there are  2 older jar 
files that you have to download and replace in the embedded
jre\lib\security directory:  local_policy.jar and US_export_policy.jar.

Obviously IBM knows about this error so how did they expect EXPLORER to work 
with the supplied jar files?
why did they not just include the correct ones to begin with.

-Original Message-
From: Barkow, Eileen
Sent: Thursday, July 21, 2016 3:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RE: IBM Z/os Explorer and CICS Explorer

I just installed the latest AQUA verion of  both explorers and could not get 
anywhere with installation manager. just download the zip file.
There was nothing about having to purchase anything.

The real fun was trying to install the features into it. the  HELP  'INSTALL 
NEW SOFTWARE' option pointed to a web site which did not let you download from.
 I finally found a humongous zip file that took all day to download but had the 
features in it.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ward, Mike S
Sent: Thursday, July 21, 2016 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Z/os Explorer and CICS Explorer

I wonder if someone from IBM that's monitoring this list can help.

I thought if you had a licensed copy of z/OS and CICS you could use the z/OS 
explorer and the CICS explorer. After using the installation manager to install 
the products it seems to indicate that you have a trial period and then you 
must purchase the products. The IBM site is so confusing I can't seem to find 
information that explains this. Can someone help?

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by replying to this e-mail 
and delete the e-mail from your system.

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

Re: S0C4 since z/OS 2.1

[Gibney, Dave]

Thanks Elardus, all valid thoughts. 
   I am backlevel on Natural, Adabas and EntireX from SAG. Moving back to 
upgrading EntireX as it also broke under z/OS 2.1

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Elardus Engelbrecht
> Sent: Thursday, July 21, 2016 2:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S0C4 since z/OS 2.1
> 
> Gibney, Dave wrote:
> 
> >There are unfortunately more than several copies of this module lying
> >around here. Someone zapped CSECT NATRUN3 The unzapped version
> works under z/OS 2.1. The zapped version does work under z/OS 1.13, but I
> have no idea what the environmental change is.
> 
> This is not looking good. What is the reason of that zaps? You should try to
> find out. Perhaps comparing any eye-catchers?
> 
> 
> >Not yet. After all, I'm running Natural 4.2.3 and the current supported
> version is what 7.4 or 8.n?
> 
> What software is 7.4 or 8.n? Are you referring to ADABAS? Or Com-Plete?
> 
> 
> >I also should add that this particular problem seems to only manifest with
> Endevor (also backlevel) under TSO/ISPF.
> 
> >I believe I was mistaken in one assumption. Moving from Linklst to Steplib
> did fix my first S0C4.
> 
> Ouch. Not ideal solution, but ...
> 
> Just compare all your loadlibs in Linklist and Steplib. Perhaps you're using
> incorrect set of load mods or libraries.
> 
> Perhaps a backlevel or incorrected compiled module(s) is a result of your
> S0C4.
> 
> Other possibility is that you need to review your exits, modules and custom
> application programs and perhaps re-compile them using z/OS v2.1 macros.
> 
> Without zaps of course if you can.
> 
> 
> >The issue I am not having seems to be that the Endevor Processor has a
> STEPLIB which is overriding the STEPLIB that has the linklsted module, so I'm,
> falling back on the failing linklsted module.
> 
> >I'd still like to know what is causing the linklsted module to fail
> >under z/OS 2.1 when it did not under z/OS 1.13
> 
> Incompatibility with z/OS v2.1 or JES2? Contact someone who has support
> with Software AG and vendor of Endevor. [1]
> 
> I certainly know that you need to upgrade your Software AG software so you
> can use it on z/OS v2.1.
> 
> No comment about Endevor, sorry. We're not using that, AFAIK.
> 
> It is a real PITA if you need to have support to resolve your problem, but you
> are out of support...
> 
> Good luck!
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> [1] - I think there is a discussion list for SAG software, just like IBM-MAIN,
> RACF-L, Assembler-L, etc.
> 
> --
> 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: DEVTYPE INFO=DASD

[Campbell Jay]

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 Reichman Joseph
Sent: Thursday, July 21, 2016 3:09 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: DEVTYPE INFO=DASD

I just got word from Jay Campbell that the device capability is 17,974 cyls I 
am getting back X'FFF0'  or 65,520, Since he is in touch with IBM I would 
suggest you contact him

Thanks  

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


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

Well, yes, but we should get the book right.  So do you mind telling me what 
the actual volume size is, just to confirm?

Reichman Joseph wrote:
> It is the first half word of each has to be
>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex 
> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> -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...
>
>
> Reichman Joseph wrote:
>> 7.2.15 Marked DEVTYPE-  info form   from DFSMSdfp "Advanced Services"  z/os 
>> V1R10.0
>>
>> Joe Reichman
>> Joe Reichman
>>
>> IT Specialist
>> Master Files Division
>> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex 
>> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
>> Cell (917) 748-9693
>> TOD M - F  7:30 am  - 4:00 pm
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] 
>> On Behalf Of Elardus Engelbrecht
>> Sent: Thursday, July 21, 2016 12:52 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: DEVTYPE INFO=DASD
>>
>> Reichman Joseph wrote:
>>
>>> The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and 
>>> bytes 4 - 7 000FF000 is tracks per cyl ? am I misreading 
>>> misunderstanding the documentation
>>
>> What docs? Could you be kind to give us the URL of that source of above info 
>> and docs?
>>
>>> I was looking for the capability on a dasd device DEVTYPE
>>> (R6),(AREA,L'AREA),INFOLIST=ILIST2
>>> ILIST2   DEVTYPE INFO=DASD
>>> AREA DSXL16
>>
>> Hmmm, interesting application of that useful macro. I must try out 
>> this little gem next week on my z/OS v2.1 sandbox when I'm returning 
>> to my bread and butter work... ;-)
>>
>>> This was the data returned in area R15 = 0
>>> FFF0 000FF000 0100 0800
>>
>> On what z/OS level were you trying to try out that Assembler snippet? How 
>> did you obtained the contents of that R15? Via a 

Re: IBM Z/os Explorer and CICS Explorer

[Barkow, Eileen]

I just installed the latest AQUA verion of  both explorers and could not get 
anywhere with installation manager. just download the zip file.
There was nothing about having to purchase anything.

The real fun was trying to install the features into it. the  HELP  'INSTALL 
NEW SOFTWARE' option pointed to a web site which did not let you download from.
 I finally found a humongous zip file that took all day to download but had the 
features in it.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ward, Mike S
Sent: Thursday, July 21, 2016 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Z/os Explorer and CICS Explorer

I wonder if someone from IBM that's monitoring this list can help.

I thought if you had a licensed copy of z/OS and CICS you could use the z/OS 
explorer and the CICS explorer. After using the installation manager to install 
the products it seems to indicate that you have a trial period and then you 
must purchase the products. The IBM site is so confusing I can't seem to find 
information that explains this. Can someone help?

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by replying to this e-mail 
and delete the e-mail from your system.

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

Re: S0C4 since z/OS 2.1

[Gibney, Dave]

I think Darrell is on the right track. The value at 001CD468 is 4074. I think 
possible (Sag code does it frequently) that the intent was to cause an 0C1, but 
with z/OS 2.1 the target isn’t valid for code and thus an 0C4 occurred.

In any case, by my earlier note, I have things working for now. 

And, of course, my long term hope is to eventually get most or all of my many 
products back up to supported levels.

It’s just a long several projects with effectively only one person doing most 
of the planning, work and archeology.  ☺

From: Software AG Discussion List [mailto:sa...@listserv.uark.edu] On Behalf Of 
Davenport, Darrell (DRS)
Sent: Thursday, July 21, 2016 6:36 AM
To: sa...@listserv.uark.edu
Subject: Re: S0C4 since z/OS 2.1

The branch 8 bytes earlier is conditional, not absolute, so it is possible it 
did not branch.  If the value at 001CD468 is 4074 (the same as R15), it 
probably got that way from the STORE statement just before the abend. If it is 
NOT 4074, then Pieter is right, it branched directly to 18C50CB0.

Because R15 is so unusual, and because it is convention to use R15 as the 
return code, my bet it that 4074 is the return code from the branch Pieter 
mentioned. It probably got stored, then was used to cause an intentional S0C1. 
So if you figure out where it just came back from, using the trace back map in 
the dump, then see if you can find a meaning for error 4074 from whatever 
module it came back from, you likely have the reason it died.

From: Software AG Discussion List [mailto:sa...@listserv.uark.edu] On Behalf Of 
Pieter Wiid
Sent: Wednesday, July 20, 2016 1:10 PM
To: sa...@listserv.uark.edu
Subject: Re: S0C4 since z/OS 2.1

Yep; in 2.1, the low 8K is “PSA”, not just 4K. You can’t update it even if you 
are key zero.
Thing is, this is not sufficient info. You would need the full dump to trace 
the instructions backward in order to determine how GPR15 got set.
Also, going by the preceding instructions, I would say there was a branch 
directly to address 18C50CB0, else you would have had the abend 8 bytes earlier.

Pieter

From: Software AG Discussion List [mailto:sa...@listserv.uark.edu] On Behalf Of 
Gibney, Dave
Sent: 20 July 2016 21:47
To: sa...@listserv.uark.edu
Subject: S0C4 since z/OS 2.1

I upgraded my Development LPAR from z/OS 1.13 to z/OS 2.1 about 2 weeks ago 
now. And for the most part, all is well.
But, I am now getting S0C4 abends in a couple of Linklsted modules. I was able 
to alleviate one of these by moving to STEPLIB access. But, this other isn’t 
cooperating as well.
I remember some talk about “better” loading of linklisted module with z/OS 2.x, 
but I thought the default was still to follow the old rules. 
This is an older version of an ISV module and I am currently out of support 
with SAG.
I’d appreciate any help or thoughts. So far, I only have the CEEDUMP. The first 
S0C4 were happening in the NAT423SH (Shared part of the Natural Nucleus) 

The value in R15 below is not good ☺
Information for enclave NATMVS  
   

   
  Information for thread 8000   
   

   
  Traceback:
   
DSA   Entry   E  Offset  Statement   Load Mod Program Unit  
 Service  Status   
1 CEEHDSP +4A4C  CEEPLPKA CEEHDSP   
 UI90017  Call 
2 +00F0  NAT423SH   
  Exception
    3 +18A8E544 
  Call 
4 +189CA8FA     
  Call 
5 +18A92AFC 
  Call 
6 +1895EBD8 
      Call 
7 NATMVS  -131C16B4  NAT423BA NATMVS
  Call 

   
DSA   DSA Addr   E  Addr    PU Addr    PU Offset  Comp Date  Compile 
Attributes    
1 0019B0C8   056508F0   056508F0   +4A4C  20150130   CEL
   
2 001CD3F8   18C50BC8   18C50BC8   +00F0    
   
3 1898CBCC   

Re: DEVTYPE INFO=DASD

[Reichman Joseph]

I just got word from Jay Campbell that the device capability is 17,974 cyls I 
am getting back X'FFF0'  or 65,520, Since he is in touch with IBM I would 
suggest you contact him

Thanks  

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


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

Well, yes, but we should get the book right.  So do you mind telling me what 
the actual volume size is, just to confirm?

Reichman Joseph wrote:
> It is the first half word of each has to be
>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex 
> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> -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...
>
>
> Reichman Joseph wrote:
>> 7.2.15 Marked DEVTYPE-  info form   from DFSMSdfp "Advanced Services"  z/os 
>> V1R10.0
>>
>> Joe Reichman
>> Joe Reichman
>>
>> IT Specialist
>> Master Files Division
>> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex 
>> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
>> Cell (917) 748-9693
>> TOD M - F  7:30 am  - 4:00 pm
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] 
>> On Behalf Of Elardus Engelbrecht
>> Sent: Thursday, July 21, 2016 12:52 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: DEVTYPE INFO=DASD
>>
>> Reichman Joseph wrote:
>>
>>> The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and 
>>> bytes 4 - 7 000FF000 is tracks per cyl ? am I misreading 
>>> misunderstanding the documentation
>>
>> What docs? Could you be kind to give us the URL of that source of above info 
>> and docs?
>>
>>> I was looking for the capability on a dasd device DEVTYPE
>>> (R6),(AREA,L'AREA),INFOLIST=ILIST2
>>> ILIST2   DEVTYPE INFO=DASD
>>> AREA DSXL16
>>
>> Hmmm, interesting application of that useful macro. I must try out 
>> this little gem next week on my z/OS v2.1 sandbox when I'm returning 
>> to my bread and butter work... ;-)
>>
>>> This was the data returned in area R15 = 0
>>> FFF0 000FF000 0100 0800
>>
>> On what z/OS level were you trying to try out that Assembler snippet? How 
>> did you obtained the contents of that R15? Via a dump or a MVC or something 
>> else?
>>
>>
>>> Mike Schwab wrote:
>>
 FFF0 000FF000 0100 0800
>>> x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per cylinder. 
>>>  Reasonable for a 3390-54.
>>
> 
>
>
> --
> 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
>


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

IBM Z/os Explorer and CICS Explorer

[Ward, Mike S]

I wonder if someone from IBM that's monitoring this list can help.

I thought if you had a licensed copy of z/OS and CICS you could use the z/OS 
explorer and the CICS explorer. After using the installation manager to install 
the products it seems to indicate that you have a trial period and then you 
must purchase the products. The IBM site is so confusing I can't seem to find 
information that explains this. Can someone help?

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Well, yes, but we should get the book right.  So do you mind telling me 
what the actual volume size is, just to confirm?


Reichman Joseph wrote:

It is the first half word of each has to be

Joe Reichman
Joe Reichman

IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


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


Reichman Joseph wrote:

7.2.15 Marked DEVTYPE-  info form   from DFSMSdfp "Advanced Services"  z/os 
V1R10.0

Joe Reichman
Joe Reichman

IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex
M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


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

Reichman Joseph wrote:


The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and
bytes 4 - 7 000FF000 is tracks per cyl ? am I misreading
misunderstanding the documentation


What docs? Could you be kind to give us the URL of that source of above info 
and docs?


I was looking for the capability on a dasd device DEVTYPE
(R6),(AREA,L'AREA),INFOLIST=ILIST2
ILIST2   DEVTYPE INFO=DASD
AREA DSXL16


Hmmm, interesting application of that useful macro. I must try out
this little gem next week on my z/OS v2.1 sandbox when I'm returning
to my bread and butter work... ;-)


This was the data returned in area R15 = 0
FFF0 000FF000 0100 0800


On what z/OS level were you trying to try out that Assembler snippet? How did 
you obtained the contents of that R15? Via a dump or a MVC or something else?



Mike Schwab wrote:



FFF0 000FF000 0100 0800

x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per cylinder.  
Reasonable for a 3390-54.






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




--
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: DEVTYPE INFO=DASD

[Reichman Joseph]

It is the first half word of each has to be 

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


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


Reichman Joseph wrote:
> 7.2.15 Marked DEVTYPE-  info form   from DFSMSdfp "Advanced Services"  z/os 
> V1R10.0
>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex 
> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] 
> On Behalf Of Elardus Engelbrecht
> Sent: Thursday, July 21, 2016 12:52 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: DEVTYPE INFO=DASD
>
> Reichman Joseph wrote:
>
>> The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and 
>> bytes 4 - 7 000FF000 is tracks per cyl ? am I misreading 
>> misunderstanding the documentation
>
> What docs? Could you be kind to give us the URL of that source of above info 
> and docs?
>
>> I was looking for the capability on a dasd device DEVTYPE
>> (R6),(AREA,L'AREA),INFOLIST=ILIST2
>> ILIST2   DEVTYPE INFO=DASD
>> AREA DSXL16
>
> Hmmm, interesting application of that useful macro. I must try out 
> this little gem next week on my z/OS v2.1 sandbox when I'm returning 
> to my bread and butter work... ;-)
>
>> This was the data returned in area R15 = 0
>> FFF0 000FF000 0100 0800
>
> On what z/OS level were you trying to try out that Assembler snippet? How did 
> you obtained the contents of that R15? Via a dump or a MVC or something else?
>
>
>> Mike Schwab wrote:
>
>>> FFF0 000FF000 0100 0800
>> x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per cylinder.  
>> Reasonable for a 3390-54.
>



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

Re: DFSORT and zIIP

[Blaicher, Christopher Y.]

One more thing - The license from IBM, at least ours, prevents a program 
running on a ZIIP from executing, or causing to be executed, user code on the 
z/IIP.

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: Thursday, July 21, 2016 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT and zIIP

On 7/21/2016 10:07 AM, Elardus Engelbrecht wrote:
> Ed Jaffe wrote:
>
>> They probably don't want to call E15/E35 exits in SRB mode, ...
> Excellent catch! Running an exit while sitting on zIIP is an interesting 
> scenario. H, very very interesting, what will happens when you try out 
> that little trick?
>
> And if you're sitting in a micro code while running some things in zIIP, what 
> will happens? Exit the zIIP and running from CPU while using those micro code 
> and jump back to zIIP?

Just to be clear, zIIP is not a different kind of hardware. It's the same 
architecture as a CP. When you're dispatched on a zIIP, you're executing 
exactly the same instructions you would execute on a CP.
You're not running "micro code" or anything like that.

SORT probably doesn't want to call E15/E35 is SRB mode because the environment 
is too restrictive for a typical E15/E35 exit. For example:
a) the call will be in supervisor state -- that could also be an integrity 
exposure
b) the code is not able to issue SVCs or perform "normal" I/O activities (GET, 
PUT, EXCP, etc.)

--
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: DEVTYPE INFO=DASD

[John Eells]

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


Reichman Joseph wrote:

7.2.15 Marked DEVTYPE-  info form   from DFSMSdfp "Advanced Services"  z/os 
V1R10.0

Joe Reichman
Joe Reichman

IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


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

Reichman Joseph wrote:


The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and bytes 4 - 7 
000FF000 is tracks per cyl ? am I misreading misunderstanding the documentation


What docs? Could you be kind to give us the URL of that source of above info 
and docs?


I was looking for the capability on a dasd device DEVTYPE
(R6),(AREA,L'AREA),INFOLIST=ILIST2
ILIST2   DEVTYPE INFO=DASD
AREA DSXL16


Hmmm, interesting application of that useful macro. I must try out this little 
gem next week on my z/OS v2.1 sandbox when I'm returning to my bread and butter 
work... ;-)


This was the data returned in area R15 = 0
FFF0 000FF000 0100 0800


On what z/OS level were you trying to try out that Assembler snippet? How did 
you obtained the contents of that R15? Via a dump or a MVC or something else?



Mike Schwab wrote:



FFF0 000FF000 0100 0800

x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per cylinder.  
Reasonable for a 3390-54.






--
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: DEVTYPE INFO=DASD

[Mike Schwab]

http://publibz.boulder.ibm.com/epubs/pdf/dgt3s310.pdf
z/OS 2.2 version, layout on page 281 (302 of 532).
Looks like significant changes with z/OS 1.10 for CYL>64K.

On Thu, Jul 21, 2016 at 12:58 PM, Reichman Joseph
 wrote:
> 7.2.15 Marked DEVTYPE-  info form   from DFSMSdfp "Advanced Services"  z/os 
> V1R10.0
>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182
> OS:CTO:AD:CP:I:IB
> Flex M,T,Th,F
> Home office (240) 863 - 3965
> Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On 
> Behalf Of Elardus Engelbrecht
> Sent: Thursday, July 21, 2016 12:52 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: DEVTYPE INFO=DASD
>
> Reichman Joseph wrote:
>
>>The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and bytes 4 - 7 
>>000FF000 is tracks per cyl ? am I misreading misunderstanding the 
>>documentation
>
> What docs? Could you be kind to give us the URL of that source of above info 
> and docs?
>
>> I was looking for the capability on a dasd device DEVTYPE
>> (R6),(AREA,L'AREA),INFOLIST=ILIST2
>> ILIST2   DEVTYPE INFO=DASD
>> AREA DSXL16
>
> Hmmm, interesting application of that useful macro. I must try out this 
> little gem next week on my z/OS v2.1 sandbox when I'm returning to my bread 
> and butter work... ;-)
>
>> This was the data returned in area R15 = 0
>> FFF0 000FF000 0100 0800
>
> On what z/OS level were you trying to try out that Assembler snippet? How did 
> you obtained the contents of that R15? Via a dump or a MVC or something else?
>
>
>>Mike Schwab wrote:
>
>>> FFF0 000FF000 0100 0800
>>x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per cylinder.  
>>Reasonable for a 3390-54.
>
> Indeed.
>
> 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
>
> --
> 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

Re: Resource Group Limits as a cost containment method?

[Edward Gould]

> On Jul 21, 2016, at 12:25 PM, Elardus Engelbrecht 
>  wrote:
> 
> Tim Hare wrote:
> 
>> 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.
> 
> What are the other STCs doing? Were they also busy or were they also idling?
> 
> 
>> 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?
> 
> Good question. If you get any good replies on that, please post them on 
> IBM-MAIN if you can. 


We had a similar issue at one company and add to the situation a real not in my 
world mind set.
I would suggest possibly bringing in a 3rd party to take a real look at the 
issue.
Some times a 3rd party can brake the log jam and start the cob webs moving.

Ed

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

Re: Kind of COND in a CLIST

[Edward Gould]

Indeed there are many ways to skin a cat.
With ISPF edit there are many ways to insert clist commands to imbed them into 
the list almost automatically.
IOW there is no best way to do this.
Use your imagination and have a got at it.
Ed

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

[Reichman Joseph]

7.2.15 Marked DEVTYPE-  info form   from DFSMSdfp "Advanced Services"  z/os 
V1R10.0 

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


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

Reichman Joseph wrote:

>The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and bytes 4 - 7 
>000FF000 is tracks per cyl ? am I misreading misunderstanding the 
>documentation

What docs? Could you be kind to give us the URL of that source of above info 
and docs?

> I was looking for the capability on a dasd device DEVTYPE 
> (R6),(AREA,L'AREA),INFOLIST=ILIST2
> ILIST2   DEVTYPE INFO=DASD 
> AREA DSXL16 

Hmmm, interesting application of that useful macro. I must try out this little 
gem next week on my z/OS v2.1 sandbox when I'm returning to my bread and butter 
work... ;-)

> This was the data returned in area R15 = 0
> FFF0 000FF000 0100 0800

On what z/OS level were you trying to try out that Assembler snippet? How did 
you obtained the contents of that R15? Via a dump or a MVC or something else?


>Mike Schwab wrote:

>> FFF0 000FF000 0100 0800
>x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per cylinder.  
>Reasonable for a 3390-54. 
 
Indeed.

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

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

Re: DFSORT and zIIP

[Ed Jaffe]

On 7/21/2016 10:07 AM, Elardus Engelbrecht wrote:

Ed Jaffe wrote:


They probably don't want to call E15/E35 exits in SRB mode, ...

Excellent catch! Running an exit while sitting on zIIP is an interesting 
scenario. H, very very interesting, what will happens when you try out that 
little trick?

And if you're sitting in a micro code while running some things in zIIP, what 
will happens? Exit the zIIP and running from CPU while using those micro code 
and jump back to zIIP?


Just to be clear, zIIP is not a different kind of hardware. It's the 
same architecture as a CP. When you're dispatched on a zIIP, you're 
executing exactly the same instructions you would execute on a CP. 
You're not running "micro code" or anything like that.


SORT probably doesn't want to call E15/E35 is SRB mode because the 
environment is too restrictive for a typical E15/E35 exit. For example:
a) the call will be in supervisor state -- that could also be an 
integrity exposure
b) the code is not able to issue SVCs or perform "normal" I/O activities 
(GET, PUT, EXCP, etc.)


--
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: Resource Group Limits as a cost containment method?

[Elardus Engelbrecht]

Tim Hare wrote:

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

What are the other STCs doing? Were they also busy or were they also idling?


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

Good question. If you get any good replies on that, please post them on 
IBM-MAIN if you can. 

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: AW: Re: Setting dump options for SVC dumps taken by StarTool DA-Batch?

[Jim Mulder]

> Yes, from the display one would assume TRT is active for SVC dumps. 
> However, viewing the flags withing the dump does *not* show TRT as 
> part of the options selected. This is what lets me think that 
> StarTool DA is specifying its own SDATA options when requesting the 
dump. 

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

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: Kind of COND in a CLIST

[Elardus Engelbrecht]

Radoslaw Skorupka wrote:

>I'm going to submit huge command list in a batch (IKJEFT01). The commands are 
>unrelated (no loops, etc.) however I want to stop the script after command 
>failure, that means RC<>0.

>Example:

>RDEF class PROFILE1.** ...
>RDEF class PROFILE2.** ...
>RDEF class PROFILE3.** ...
>...
>PERMIT profile1.** ID(some grp) ACC(UPDATE)

>Let's say second command fails (RDEF PROFILE2) so, script is aborted, RDEF 
>PROFILE3 is not issued.

I would go the way Lizette said. Put your commands in a dataset. Create a REXX 
program, read line by line and execute them. Check your RC based on the result 
of each command. Exit loop if RC <> 0.

Based on the RDEF result, you could simply skip those PERMIT commands, by 
checking the profile in RACF.

It should not be too hard to do that. [1] 

I would also consider other's replies. They are very interesting alternatives. 
Many ways to skin this little cat!

Groete / Greetings
Elardus Engelbrecht


[1] - I have several REXX programs which are doing more or less the same. Read 
a Dataset with info, parse each line, create RACF commands and place them in a 
dataset for review. If all is Ok, then I simple execute them.

Oh, yes, I have written on RACF-L, years ago, that I wrote a REXX program using 
ISPF panels to create / modify one id or a range of ids by creating RACF 
commands. This program issues a LU command and either create AU or ALU commands 
depending whether the ids are already defined in RACF. The same goes for mass 
deletion of ids.

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

Re: DFSORT and zIIP

[Elardus Engelbrecht]

Ed Jaffe wrote:

>They probably don't want to call E15/E35 exits in SRB mode, ...

Excellent catch! Running an exit while sitting on zIIP is an interesting 
scenario. H, very very interesting, what will happens when you try out that 
little trick?

And if you're sitting in a micro code while running some things in zIIP, what 
will happens? Exit the zIIP and running from CPU while using those micro code 
and jump back to zIIP?

Any doumentation available discussing above scenarios?

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

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

[Peter Hunkeler]

>> Does anyone know how I can change that? System DUMP options for
>> SYSABEND, SYSMDUMP, and SDUMP have the SDATA(...TRT...). Only
>> SYSUDUMP has Just SDATA=(SUM), but that should not apply in our case.
 >
>What is displayed by the D D,O   command on your system?


The above paragraph is a summary from the D D,O command and I thought it would 
be clear. It seems, it is not. Sorry.


Yes, from the display one would assume TRT is active for SVC dumps. However, 
viewing the flags withing the dump does *not* show TRT as part of the options 
selected. This is what lets me think that StarTool DA is specifying its own 
SDATA options when requesting the dump.


>Under IPCS, what does  VERBX IEAVTSFS display for Partial Dump Reason
Codes?




I'm at home now, but will check the above tomorrow.


--
Peter Hunkeler



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

AW: Resource Group Limits as a cost containment method?

[Peter Hunkeler]

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




At month ends, we were hitting the Group Capacity Limits repeatedly, and the 
systems were capping when the online work started in the morning.


During the night and early morning before online, batch had a lot of capacity 
to use and it did use it. We introduced Resource Groups to limit what batch can 
consume in the early morning. The goal was to bring down the R4HA until when 
online start, and thereby make sure we will not get into capping.


We're using Resource Grpups with great success since March this year. No 
negtive impact seen so far.


We defined a couple of WLM policies with different Resource Group Max values, 
so we can easily and quickly adjust the amount of capacity batch can use. We're 
using type 2, i.e. percentage of LPAR capacity.


We're using policy overrides to override the Resource Group MAX value instead 
of changing the Resource Group assignment in the Service Classes. In other 
words, there is only one Resource Group and it is assigned to all batch Service 
Classes (except from an "emergeny" class). The RG MAX value is different in 
each Service Policy. The later are named someting like RG_B10, RG_B12, etc. The 
digits represent the percentage assigned. In the base policy, the RG does not 
have a MAX value. MIN values are always empty (0).


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

Re: DEVTYPE INFO=DASD

[Mike Schwab]

The BDW / RDW length field for V files is a 4 byte length field with
the first 2 bytes binary length.

On Thu, Jul 21, 2016 at 11:51 AM, Elardus Engelbrecht
 wrote:
> Reichman Joseph wrote:
>
>>The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and bytes 4 - 7 
>>000FF000 is tracks per cyl ? am I misreading misunderstanding the 
>>documentation
>
> What docs? Could you be kind to give us the URL of that source of above info 
> and docs?
>
>> I was looking for the capability on a dasd device
>> DEVTYPE (R6),(AREA,L'AREA),INFOLIST=ILIST2
>> ILIST2   DEVTYPE INFO=DASD
>> AREA DSXL16
>
> Hmmm, interesting application of that useful macro. I must try out this 
> little gem next week on my z/OS v2.1 sandbox when I'm returning to my bread 
> and butter work... ;-)
>
>> This was the data returned in area R15 = 0
>> FFF0 000FF000 0100 0800
>
> On what z/OS level were you trying to try out that Assembler snippet? How did 
> you obtained the contents of that R15? Via a dump or a MVC or something else?
>
>
>>Mike Schwab wrote:
>
>>> FFF0 000FF000 0100 0800
>>x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per cylinder.  
>>Reasonable for a 3390-54.
>
> Indeed.
>
> 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



-- 
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: DEVTYPE INFO=DASD

[Elardus Engelbrecht]

Reichman Joseph wrote:

>The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and bytes 4 - 7 
>000FF000 is tracks per cyl ? am I misreading misunderstanding the 
>documentation

What docs? Could you be kind to give us the URL of that source of above info 
and docs?

> I was looking for the capability on a dasd device 
> DEVTYPE (R6),(AREA,L'AREA),INFOLIST=ILIST2 
> ILIST2   DEVTYPE INFO=DASD 
> AREA DSXL16 

Hmmm, interesting application of that useful macro. I must try out this little 
gem next week on my z/OS v2.1 sandbox when I'm returning to my bread and butter 
work... ;-)

> This was the data returned in area R15 = 0 
> FFF0 000FF000 0100 0800 

On what z/OS level were you trying to try out that Assembler snippet? How did 
you obtained the contents of that R15? Via a dump or a MVC or something else?


>Mike Schwab wrote:

>> FFF0 000FF000 0100 0800 
>x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per cylinder.  
>Reasonable for a 3390-54. 
 
Indeed.

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: Setting dump options for SVC dumps taken by StarTool DA-Batch?

[Jim Mulder]

> We're using both SmartRestart as well as StarTool DA. As far as I 
> understand, SmartRestart asks StarTool DA , The former recognizes 
> the ABEND (0C4 in this case) and it recognizes that StarTool DA is 
> also present. Since there is a //SYSUDUMP DD card in the jobstep, it
> sks StarTool to schedule an SVC dump.
> 
> The dump is fine with the exception that my beloved System Trace is 
> not present, because it was not requested via SDATA option.
> 
> 
> Does anyone know how I can change that? System DUMP options for 
> SYSABEND, SYSMDUMP, and SDUMP have the SDATA(...TRT...). Only 
> SYSUDUMP has Just SDATA=(SUM), but that should not apply in our case.

  Parmlib member IEACMD00 contains
COM='CHNGDUMP SET,SDUMP=(LSQA,TRT,XESDATA),ADD' 

  So all SVC dumps should have system trace.

What is displayed by the D D,O   command on your system?

Under IPCS, what does  VERBX IEAVTSFS display for Partial Dump Reason 
Codes?

And what does   CBF RTCT+9C? STR(SDUMP) VIEW(FLAGS) show for
SDATA options? 


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: Kind of COND in a CLIST

[Paul Gilmartin]

On Thu, 21 Jul 2016 09:00:52 -0700, Lizette Koehler wrote:

>I would think putting your commands in a DATASET, then using REXX to execute
>them one at a time and check the return code would work.
> 
With Rexx I'd use SIGNAL ON NOVALUE and wrap the few commands for
which RC<>0 with call to a subroutine that locally disables the trap.

I have several jobs with a two-statement SYSTSIN that REPROs another
SYSIN to a temporary PDS then EXECs that member.

Theres a hack that can be used to run a Rexx EXEC directly from SYSIN.
It's documented only indirectly and probably unsupported.  I don't
use it.

-- gil

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

[John McKown]

On Thu, Jul 21, 2016 at 11:13 AM, Hardee, Chuck <
chuck.har...@thermofisher.com> wrote:

> No, my requirement is batch.
> The service executing in its own address space that I need to access
> issues an EXCLUSIVE ENQ for a determinable QName/RName when it is up and
> ready to receive requests. I need to know if it is up and ready to receive
> before issuing any requests to it.
> This is all done in a batch address space, no CICS involved here.
>
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology
>
> Thermo Fisher Scientific
>
>
​Bottom line: HLASM or C with embedded assembler (if you're on z/OS 2.2
with the latest IBM C/C++ compiler).​




-- 
"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: OS ENQ from COBOL

[Hardee, Chuck]

Yes, I found nothing in the Unix, LE or C/C++ services that perform an ENQ of 
any kind, be it for control or for testing availability.

I agree, the only real reason someone other than myself would need to do 
anything to the code is to reassemble it if the ENQ macro were to change. Since 
it would be single function, test if QName/RName is available or not, I would 
suspect the code wouldn't have to be changed, if ever.

I am just trying to do due diligence and make sure I'm not reinventing the 
wheel.

Thanks!

C-

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 Bill Woodger
Sent: Thursday, July 21, 2016 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: OS ENQ from COBOL

There's nothing native in COBOL to do an what you want, and I'm not aware of 
anything in LE as a callable service.

Hybrid. Documentation. Probably the most they'll need is how to reassemble it. 
Unless a macro changes, why else would they ever need to touch it?

--
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: OS ENQ from COBOL

[Hardee, Chuck]

No, my requirement is batch.
The service executing in its own address space that I need to access issues an 
EXCLUSIVE ENQ for a determinable QName/RName when it is up and ready to receive 
requests. I need to know if it is up and ready to receive before issuing any 
requests to it.
This is all done in a batch address space, no CICS involved here.

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 Joseph W Gentile
Sent: Thursday, July 21, 2016 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OS ENQ from COBOL

I don't know if you are running in a CICS environment but CICS has an EXEC 
CICS ENQ service. Perhaps you can invoke it (non-blocking) to figure out 
if the resource is held? Admittedly not the most straightforward 
approach... 
https://www.ibm.com/support/knowledgecenter/SSGMCP_5.2.0/com.ibm.cics.ts.applicationprogramming.doc/commands/dfhp4_enq.html

-Joe

Joe Gentile
z/OS GRS and RSM Development
(845)435-2184 (T/L 295-2184)
jwgen...@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

Re: Kind of COND in a CLIST

[Lizette Koehler]

I would think putting your commands in a DATASET, then using REXX to execute
them one at a time and check the return code would work.

If it is required to do it with a CLIST then the same logic would work.




Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Thursday, July 21, 2016 5:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Kind of COND in a CLIST
> 
> I'm going to submit huge command list in a batch (IKJEFT01). The commands are
> unrelated (no loops, etc.) however I want to stop the script after command
> failure, that means RC<>0.
> 
> Example:
> //STEP1   EXEC PGM=IKJEFT01
> //SYSTSPRT DD  SYSOUT=*
> //SYSTSIN  DD  *,DLM=@@
> /* command list */
> RDEF class PROFILE1.** ...
> RDEF class PROFILE2.** ...
> RDEF class PROFILE3.** ...
> ...
> PERMIT profile1.** ID(some grp) ACC(UPDATE) PERMIT profile2.** ID(some grp)
> ACC(UPDATE) PERMIT profile3.** ID(some grp) ACC(UPDATE) ...
> 
> Let's say second command fails (RDEF PROFILE2) so, script is aborted, RDEF
> PROFILE3 is not issued.
> 
> Any clue?
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 

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

OS ENQ from COBOL

[Bill Woodger]

There's nothing native in COBOL to do an what you want, and I'm not aware of 
anything in LE as a callable service.

Hybrid. Documentation. Probably the most they'll need is how to reassemble it. 
Unless a macro changes, why else would they ever need to touch it?

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

[Roach, Dennis]

RCTLACS contains the current running average for the LPAR.
Assuming a single LAPR, it is possible to monitor and adjust the cap by 
changing the WLM policy (V WLM,policyname).
This requires at least 2 policies. 1 with no caps and 1 without caps. You may 
need another with tighter caps in order to force the value down.

If this is a multiple LPAR CEC you need to look at the value for all LPARS. I 
have use CA/OPS to do this.

Dennis Roach, CISSP, PMP
AIG
IAM Access Administration – Consumer | Identy & Access Management

2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
Phone:  713-831-8799

dennis.ro...@aig.com | www.aig.com 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tim Hare
Sent: Thursday, July 21, 2016 9:59 AM
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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFSORT and zIIP

[Ed Jaffe]

On 7/20/2016 11:25 PM, Timothy Sipples wrote:


To my knowledge, no. zIIP exploitation sometimes makes technical sense, and
sometimes it doesn't. Even within the same general product category.
Subject to periodic review as technologies change and evolve.


Assuming they're constrained by the same "Enclave SRB Only" restriction 
placed upon ISV zIIP exploiters, then a lot depends on how many task 
mode-only system services are being invoked by the code. Switching back 
and forth from task to SRB mode is expensive -- not just because of the 
extra path length, but also because of cache considerations.


They probably don't want to call E15/E35 exits in SRB mode, but it seems 
like they should be able to load the data in task mode, sort the data in 
SRB mode, and then write the data back out in task mode.


--
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: OS ENQ from COBOL

[Joseph W Gentile]

I don't know if you are running in a CICS environment but CICS has an EXEC 
CICS ENQ service. Perhaps you can invoke it (non-blocking) to figure out 
if the resource is held? Admittedly not the most straightforward 
approach... 
https://www.ibm.com/support/knowledgecenter/SSGMCP_5.2.0/com.ibm.cics.ts.applicationprogramming.doc/commands/dfhp4_enq.html

-Joe

Joe Gentile
z/OS GRS and RSM Development
(845)435-2184 (T/L 295-2184)
jwgen...@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: DEVTYPE INFO=DASD

[Reichman Joseph]

The doc says bytes 0 - 3 is cylinders bytes 0 -3 is FFF0 and bytes 4 - 7 
000FF000 is tracks per cyl ? am I misreading misunderstanding the documentation 
  

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Mike Schwab
Sent: Thursday, July 21, 2016 11:36 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: DEVTYPE INFO=DASD

> FFF0 000FF000 0100 0800

x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per cylinder.  
Reasonable for a 3390-54.

On Thu, Jul 21, 2016 at 9:00 AM, Reichman Joseph  
wrote:
> Hi
>
> I was looking for the capability on a dasd device
>
>
> DEVTYPE (R6),(AREA,L'AREA),INFOLIST=ILIST2
>
> ILIST2   DEVTYPE INFO=DASD
>
> AREA DSXL16
>
> This was the data returned in area R15 = 0
>
> FFF0 000FF000 0100 0800
>
>
>
> DASD  Returns 16 bytes as follows:
>
> Bytes 0-3 Number of cylinders on the device, excluding alternates. For a VIO 
> data set, this number is the number of simulated cylinders needed to contain 
> the data set.
>
> Bytes4-7 Number of tracks per cylinder.
>
>
> Seems to indicate over 4 million cylinders and over 100,000 tracks on the 
> volume ?
>
>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex 
> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> --
> 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

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

[Mike Schwab]

> FFF0 000FF000 0100 0800

x'FFF0' would be 65520 cylinders.  x'000F' would be 15 tracks per
cylinder.  Reasonable for a 3390-54.

On Thu, Jul 21, 2016 at 9:00 AM, Reichman Joseph
 wrote:
> Hi
>
> I was looking for the capability on a dasd device
>
>
> DEVTYPE (R6),(AREA,L'AREA),INFOLIST=ILIST2
>
> ILIST2   DEVTYPE INFO=DASD
>
> AREA DSXL16
>
> This was the data returned in area R15 = 0
>
> FFF0 000FF000 0100 0800
>
>
>
> DASD  Returns 16 bytes as follows:
>
> Bytes 0-3 Number of cylinders on the device, excluding alternates. For a VIO 
> data set, this number is the number of simulated cylinders needed to contain 
> the data set.
>
> Bytes4-7 Number of tracks per cylinder.
>
>
> Seems to indicate over 4 million cylinders and over 100,000 tracks on the 
> volume ?
>
>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182
> OS:CTO:AD:CP:I:IB
> Flex M,T,Th,F
> Home office (240) 863 - 3965
> Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> --
> 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

Re: SHARE Webcast: SHARE Academy and New to z Systems

[Don Poitras]

Tom,
  Excellent. Thanks. It seems to be documented kind of inside-out. :)

In article <2692326115030948.wa.m42tomibmmainyahoo@listserv.ua.edu> you 
wrote:
> On Wed, 20 Jul 2016 18:20:19 -0400, Don Poitras wrote:

> >I needed to know what bit represents a BAKR
> >call vs. a PC. This is all I could find:
> >
> >---
> >Bytes 288-295 contain the entry
> >descriptor. EXTRACT STACKED STATE sets the
> >condition code to indicate whether the entry-type
> >code in the entry descriptor specifies a branch state
> >entry or a program-call state entry.

> In the -10 edition of the POO, it is on page 5-80, under the heading "Entry 
> Descriptors". 

> 
> Entry Type (ET): Bits 1-7 are a code that specifies
> the type of the linkage-stack entry containing the
> entry descriptor. The assigned codes are:

> Code (in Binary)   Entry Type   
> 0001001Header entry 
> 0001010Trailer entry
> 0001100Branch State entry   
> 0001101Program-call state entry 

> Codes 000-0001000, 0001011, and 0001110
> through 011 binary are reserved for possible
> future assignments. Codes 100 through
> 111 binary are available for use by programming.
> 

> Tom Marchant

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

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

[Peter Hunkeler]

We're using both SmartRestart as well as StarTool DA. As far as I understand, 
SmartRestart asks StarTool DA , The former recognizes the ABEND (0C4 in this 
case) and it recognizes that StarTool DA is also present. Since there is a 
//SYSUDUMP DD card in the jobstep, it sks StarTool to schedule an SVC dump.

The dump is fine with the exception that my beloved System Trace is not 
present, because it was not requested via SDATA option.


Does anyone know how I can change that? System DUMP options for SYSABEND, 
SYSMDUMP, and SDUMP have the SDATA(...TRT...). Only SYSUDUMP has Just 
SDATA=(SUM), but that should not apply in our case.




Before you ask: No I have not asked the ISVs since I'm not in the position to 
ask them.




--
Peter Hunkeler

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

Re: Real purpose of hipersocket

[Tim Hare]

I would like to add one other advantage that I took advantage of.  When you 
define your hipersocket network,  you can define a very large MTU size for the 
hipersocket network.  This can eliminate a lot of segmentation/re-assembly 
overhead because the data transmission is broken up into fewer large pieces.  
This really can help elapsed time for  transmission of large things like FTP of 
large files, NJE transmission of large reports, or perhaps DRDA between 
database systems, and I never noticed any downside for smaller things.

As mentioned previously, both networks can co-exist, and you can define the 
routing so that hipersockets are preferred.  I don't have my definitions handy 
but we used VIPAs and so we could reach the zOS image via either of two IP 
addresses.  We used 192.168.x.x addresses for the internal (hipersocket) 
network;  I recommend making the last octet or the last two octets the same as 
those of the OSA IP address, but it's not required.

You can test the difference in speed -  find a large dataset (or create one),  
and FTP it using the OSA network and the other system's non-hipersocket IP 
address,  then FTP the same file using the hipersocket IP address.

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

Re: SHARE Webcast: SHARE Academy and New to z Systems

[Tom Marchant]

On Wed, 20 Jul 2016 18:20:19 -0400, Don Poitras wrote:

>I needed to know what bit represents a BAKR
>call vs. a PC. This is all I could find:
>
>---
>Bytes 288-295 contain the entry
>descriptor. EXTRACT STACKED STATE sets the
>condition code to indicate whether the entry-type
>code in the entry descriptor specifies a branch state
>entry or a program-call state entry.

In the -10 edition of the POO, it is on page 5-80, under the heading "Entry 
Descriptors". 


Entry Type (ET): Bits 1-7 are a code that specifies
the type of the linkage-stack entry containing the
entry descriptor. The assigned codes are:

Code (in Binary)   Entry Type   
0001001Header entry 
0001010Trailer entry
0001100Branch State entry   
0001101Program-call state entry 

Codes 000-0001000, 0001011, and 0001110
through 011 binary are reserved for possible
future assignments. Codes 100 through
111 binary are available for use by programming.


Tom Marchant

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

Resource Group Limits as a cost containment method?

[Tim Hare]

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

Re: Kind of COND in a CLIST

[Mick Graley]

Also if you were to create a CLIST for this as suggested previously,
rather than adding lots of IFs or WHENs, you should just be able to
specify CONTROL FLUSH once at the beginning of the CLIST.

Mick.


On 21 July 2016 at 14:24, Norbert Friemel  wrote:
> On Thu, 21 Jul 2016 14:36:30 +0200, R.S. wrote:
>
>> I'm going to submit huge command list in a batch (IKJEFT01). The
>> commands are unrelated (no loops, etc.) however I want to stop the
>> script after command failure, that means RC<>0.
>>
>> Example:
>> //STEP1   EXEC PGM=IKJEFT01
>> //SYSTSPRT DD  SYSOUT=*
>> //SYSTSIN  DD  *,DLM=@@
>> /* command list */
>> RDEF class PROFILE1.** ...
>> RDEF class PROFILE2.** ...
>
> Replace IKJEFT01 with IKJEFT1A (or IKJEFT1B)?
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikjc200/jcl_exec.htm
>
> Norbert Friemel
>
> --
> 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

DEVTYPE INFO=DASD

[Reichman Joseph]

Hi

I was looking for the capability on a dasd device


DEVTYPE (R6),(AREA,L'AREA),INFOLIST=ILIST2

ILIST2   DEVTYPE INFO=DASD

AREA DSXL16

This was the data returned in area R15 = 0

FFF0 000FF000 0100 0800



DASD  Returns 16 bytes as follows:

Bytes 0-3 Number of cylinders on the device, excluding alternates. For a VIO 
data set, this number is the number of simulated cylinders needed to contain 
the data set.

Bytes4-7 Number of tracks per cylinder.


Seems to indicate over 4 million cylinders and over 100,000 tracks on the 
volume ?


Joe Reichman
Joe Reichman

IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


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

Re: AW: Re: DFSORT and zIIP

[Ed Jaffe]

On 7/20/2016 10:45 PM, Peter Hunkeler wrote:
I'm longing for the day when also the zIIPs disappear again and IBM 
has found a better way to charge software license fees. 


I agree it would be GREAT(!) if kneecapping of CPs was removed and 
replaced with PER CORE software charging like other platforms use. Until 
that day arrives, specialty engines are the only way for small and 
medium-sized companies to fully experience the current awesomeness of z 
Systems processor technology.


BTW, some recent performance studies have shown that kneecapping can 
actually improve performance in larger shops by increasing the number of 
dispatch points. For example, take a look at the results enumerated in 
this "Best Session Award" presentation from SHARE in San Antonio: 
http://share.confex.com/data/handout/share/126/Session_18345_handout_8753_0.pdf


--
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: Kind of COND in a CLIST

[Norbert Friemel]

On Thu, 21 Jul 2016 14:36:30 +0200, R.S. wrote:

> I'm going to submit huge command list in a batch (IKJEFT01). The
> commands are unrelated (no loops, etc.) however I want to stop the
> script after command failure, that means RC<>0.
> 
> Example:
> //STEP1   EXEC PGM=IKJEFT01
> //SYSTSPRT DD  SYSOUT=*
> //SYSTSIN  DD  *,DLM=@@
> /* command list */
> RDEF class PROFILE1.** ...
> RDEF class PROFILE2.** ...

Replace IKJEFT01 with IKJEFT1A (or IKJEFT1B)?
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikjc200/jcl_exec.htm

Norbert Friemel

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

Re: Kind of COND in a CLIST

[Walt Farrell]

On Thu, 21 Jul 2016 14:36:30 +0200, R.S.  wrote:

>I'm going to submit huge command list in a batch (IKJEFT01). The 
>commands are unrelated (no loops, etc.) however I want to stop the 
>script after command failure, that means RC<>0.
>
>Example:
>//STEP1   EXEC PGM=IKJEFT01
>//SYSTSPRT DD  SYSOUT=*
>//SYSTSIN  DD  *,DLM=@@
>/* command list */
>RDEF class PROFILE1.** ...
>RDEF class PROFILE2.** ...
>RDEF class PROFILE3.** ...
>...
>
>Let's say second command fails (RDEF PROFILE2) so, script is aborted, 
>RDEF PROFILE3 is not issued.
>
>Any clue?

First, that's not a CLIST (as implied in your subject line). It's merely a list 
of TSO commands. If it were a CLIST, then possibly using the WHEN command after 
each command could solve your problem. It is documented as working after CALL 
and LOADGO commands, but might work after other commands, too. WHEN (SYSRC > 0) 
END would be useful in a CLIST if it works after other commands.

Even without it being a CLIST, WHEN might work, but I can't run an experiment 
to find out. Perhaps WHEN (SYSRC > 0) LOGOFF would do it?

-- 
Walt

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

Re: Kind of COND in a CLIST

[Hardee, Chuck]

Radoslaw,

I would put the commands into a CLIST (or REXX) and add IF logic to check the 
return code from each command and EXIT when it's not an acceptable value.

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 R.S.
Sent: Thursday, July 21, 2016 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Kind of COND in a CLIST

I'm going to submit huge command list in a batch (IKJEFT01). The 
commands are unrelated (no loops, etc.) however I want to stop the 
script after command failure, that means RC<>0.

Example:
//STEP1   EXEC PGM=IKJEFT01
//SYSTSPRT DD  SYSOUT=*
//SYSTSIN  DD  *,DLM=@@
/* command list */
RDEF class PROFILE1.** ...
RDEF class PROFILE2.** ...
RDEF class PROFILE3.** ...
...
PERMIT profile1.** ID(some grp) ACC(UPDATE)
PERMIT profile2.** ID(some grp) ACC(UPDATE)
PERMIT profile3.** ID(some grp) ACC(UPDATE)
...

Let's say second command fails (RDEF PROFILE2) so, script is aborted, 
RDEF PROFILE3 is not issued.

Any clue?

-- 
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Kind of COND in a CLIST

[R.S.]

I'm going to submit huge command list in a batch (IKJEFT01). The 
commands are unrelated (no loops, etc.) however I want to stop the 
script after command failure, that means RC<>0.


Example:
//STEP1   EXEC PGM=IKJEFT01
//SYSTSPRT DD  SYSOUT=*
//SYSTSIN  DD  *,DLM=@@
/* command list */
RDEF class PROFILE1.** ...
RDEF class PROFILE2.** ...
RDEF class PROFILE3.** ...
...
PERMIT profile1.** ID(some grp) ACC(UPDATE)
PERMIT profile2.** ID(some grp) ACC(UPDATE)
PERMIT profile3.** ID(some grp) ACC(UPDATE)
...

Let's say second command fails (RDEF PROFILE2) so, script is aborted, 
RDEF PROFILE3 is not issued.


Any clue?

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

CMP country multiplex pricing

[Tommy Tsui]

Hi all,
Any shop apply the CMP, anything we need to aware before apply CMP, thank
for sharing

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

Re: DFSORT and zIIP

[R.S.]

W dniu 2016-07-21 o 08:25, Timothy Sipples pisze:

Paul Gilmartin wrote:

I find it hard to believe that optimization of revenue was not a

consideration.

To my knowledge, no. zIIP exploitation sometimes makes technical sense, and
sometimes it doesn't. Even within the same general product category.
Subject to periodic review as technologies change and evolve.


In general zIIP exploitation is for financial reasons. By definition. It 
is still the same CPU as CP, with somehow limited functionality to 
support some workloads, approved by IBM.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

Re: S0C4 since z/OS 2.1

[Elardus Engelbrecht]

Gibney, Dave wrote:

>There are unfortunately more than several copies of this module lying around 
>here. Someone zapped CSECT NATRUN3 
>The unzapped version works under z/OS 2.1. The zapped version does work under 
>z/OS 1.13, but I have no idea what the environmental change is.

This is not looking good. What is the reason of that zaps? You should try to 
find out. Perhaps comparing any eye-catchers?


>Not yet. After all, I'm running Natural 4.2.3 and the current supported 
>version is what 7.4 or 8.n? 

What software is 7.4 or 8.n? Are you referring to ADABAS? Or Com-Plete?


>I also should add that this particular problem seems to only manifest with 
>Endevor (also backlevel) under TSO/ISPF.

>I believe I was mistaken in one assumption. Moving from Linklst to Steplib did 
>fix my first S0C4. 

Ouch. Not ideal solution, but ...

Just compare all your loadlibs in Linklist and Steplib. Perhaps you're using 
incorrect set of load mods or libraries. 

Perhaps a backlevel or incorrected compiled module(s) is a result of your S0C4.

Other possibility is that you need to review your exits, modules and custom 
application programs and perhaps re-compile them using z/OS v2.1 macros.

Without zaps of course if you can.


>The issue I am not having seems to be that the Endevor Processor has a STEPLIB 
>which is overriding the STEPLIB that has the linklsted module, so I'm, falling 
>back on the failing linklsted module.

>I'd still like to know what is causing the linklsted module to fail under z/OS 
>2.1 when it did not under z/OS 1.13

Incompatibility with z/OS v2.1 or JES2? Contact someone who has support with 
Software AG and vendor of Endevor. [1]

I certainly know that you need to upgrade your Software AG software so you can 
use it on z/OS v2.1.

No comment about Endevor, sorry. We're not using that, AFAIK.

It is a real PITA if you need to have support to resolve your problem, but you 
are out of support...

Good luck!

Groete / Greetings
Elardus Engelbrecht

[1] - I think there is a discussion list for SAG software, just like IBM-MAIN, 
RACF-L, Assembler-L, etc.

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

Re: DFSORT and zIIP

[Timothy Sipples]

Paul Gilmartin wrote:
>I find it hard to believe that optimization of revenue was not a
consideration.

To my knowledge, no. zIIP exploitation sometimes makes technical sense, and
sometimes it doesn't. Even within the same general product category.
Subject to periodic review as technologies change and evolve.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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