IBM Acquiring EZSource Code Analysis Tools

[Timothy Sipples]

There's some interesting mainframe business news today. IBM just announced
the pending acquisition of the company behind the EZSource development
tools. Here's the press release:

"IBM to Acquire EZSource to Help Developers Modernize Mainframe
Applications for Digital Business"
http://www.ibm.com/press/us/en/pressrelease/49810.wss

and here's the link to EZSource product information:

http://www.ezsource.com

IBM expects the acquisition to be closed later this quarter (second
calendar quarter, 2016).

The EZSource Eclipse-based tools are already well integrated with IBM
Rational tools such as Rational Developer for z Systems (RDz) and Rational
Team Concert (RTC) and with many other tools and platforms. More to come, I
expect.


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

Re: Migration to Enterprise COBOL V5.2

[Mike Schwab]

You will need to maintain compatibility with your lowest level of
hardware, prime or DR.

On Wed, Jun 1, 2016 at 4:44 PM, Bill Woodger  wrote:
> Why wouldn't ARCH(11) give the best performance? V5.2 has it? Of course, has 
> to be for a z13.
>
> I'm not sure what you mean about REGION=0M. At least 200M will be needed, 
> more for large programs. See here: 
> http://www.ibm.com/support/knowledgecenter/SSQ2R2_9.0.0/com.ibm.ent.cbl.zos.doc/migrate/igymbhv.html.
>  If 0M doesn't get enough memory, it will need to be changed.
>
> ARCH for DRS/BRS is covered in the Migration Guide, and is obviously 
> important.
>
> What issue are you aware of with CANCEL from V4.2 to V5.2?
>
> The behaviour of STRING with the same source and target is undefined by the 
> COBOL Standard (1985 and later). Whether the undefined behaviour is different 
> with the new compiler I don't know, but it doesn't matter if it is (such code 
> would be unreliable under any previous IBM COBOL compiler).
>
> IF FIELD = ZERO is not necessarily false for 4.2 or true for 5.2, it depends. 
> Certainly incorrect zones in data can cause different behaviours. With PACK 
> and CP for a "USAGE DISPLAY" field, the zones are quietly ignored. With CLC, 
> that matters. Possibly with DFP, I don't know. V4.2 uses both PACK/CP and CLC 
> at different times depending on compiler options and whether fields are 
> signed. V5.2 probably has more different ways to do it. See here, 
> https://www.ibm.com/developerworks/community/forums/html/topic?id=22ae65fe-5199-426a-bc61-3cc340d726c2=25,
>  for some discussion.
>
>  On Wednesday, 1 June 2016 20:16:37 UTC+2, Salva Carrasco  wrote:
>> - Test(DWARF): Increase size in library but not in memory, debug data is 
>> only loaded at error/abend time.
>> - Best CPU usage if using Arch(9/10) on execution.
>> - Worst compile CPU/Time/Storage. REGION=0M, IEFUSI, ...
>> - Take an eye on latest maintenance, specially LE.
>> - Be aware of Arch level for your BRS site.
>> - Be aware of CANCEL sentence for mixed 4.2 & 5.2 Cobol load modules.
>> . Be aware of STRING sentence when using same source & target data field.
>> - Be aware of low-values decimal zones. IF FIELD = ZERO, false for 4.2, true 
>> for 5.2. Look at ZONEDATA *new* option.
>
> --
> 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

Migration to Enterprise COBOL V5.2

[Bill Woodger]

Why wouldn't ARCH(11) give the best performance? V5.2 has it? Of course, has to 
be for a z13.

I'm not sure what you mean about REGION=0M. At least 200M will be needed, more 
for large programs. See here: 
http://www.ibm.com/support/knowledgecenter/SSQ2R2_9.0.0/com.ibm.ent.cbl.zos.doc/migrate/igymbhv.html.
 If 0M doesn't get enough memory, it will need to be changed.

ARCH for DRS/BRS is covered in the Migration Guide, and is obviously important.

What issue are you aware of with CANCEL from V4.2 to V5.2?

The behaviour of STRING with the same source and target is undefined by the 
COBOL Standard (1985 and later). Whether the undefined behaviour is different 
with the new compiler I don't know, but it doesn't matter if it is (such code 
would be unreliable under any previous IBM COBOL compiler).

IF FIELD = ZERO is not necessarily false for 4.2 or true for 5.2, it depends. 
Certainly incorrect zones in data can cause different behaviours. With PACK and 
CP for a "USAGE DISPLAY" field, the zones are quietly ignored. With CLC, that 
matters. Possibly with DFP, I don't know. V4.2 uses both PACK/CP and CLC at 
different times depending on compiler options and whether fields are signed. 
V5.2 probably has more different ways to do it. See here, 
https://www.ibm.com/developerworks/community/forums/html/topic?id=22ae65fe-5199-426a-bc61-3cc340d726c2=25,
 for some discussion.

 On Wednesday, 1 June 2016 20:16:37 UTC+2, Salva Carrasco  wrote:
> - Test(DWARF): Increase size in library but not in memory, debug data is only 
> loaded at error/abend time.
> - Best CPU usage if using Arch(9/10) on execution.
> - Worst compile CPU/Time/Storage. REGION=0M, IEFUSI, ...
> - Take an eye on latest maintenance, specially LE.
> - Be aware of Arch level for your BRS site.
> - Be aware of CANCEL sentence for mixed 4.2 & 5.2 Cobol load modules.
> . Be aware of STRING sentence when using same source & target data field.
> - Be aware of low-values decimal zones. IF FIELD = ZERO, false for 4.2, true 
> for 5.2. Look at ZONEDATA *new* option.

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

Migration to Enterprise COBOL V5.2

[Bill Woodger]

Are there no internal IBM methods of asking?

There's the COBOL Cafe at the Compile Cafe: 
https://www.ibm.com/developerworks/community/forums/html/forum?id=----2281,
 a couple of compiler developers visit. There's also some advice posted there, 
and elsewhere.

If the site has *very large* programs, V6.1 could/would be a better choice, as 
the compiler uses 64-bit addressing allowing it to consume larger programs more 
efficiently (or at all for OPT(2)).

Without knowing which compiler options have been chosen, it is difficult to say 
about the size. Unless it is the debugging, 3-4 times the size for OPT(2) 
sounds excessive, as does 50% for OPT(0). OPT(0) does do some optimisation. 
In-lining of some PERFORMs does increase size. Prior to V5 there is a "cap" to 
the size increase. I don't know that that has changed.

Consult the fix list, 
http://www-01.ibm.com/support/docview.wss?uid=swg27041164, and review what is 
and isn't applied already. 

CPU times should generally improve, and should be noticeable.

Hopefully the compile options chosen are largely those already in use. Note 
that there are some new "diagnosis"-type options which can help to identify 
things which could cause different behaviours.

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

Re: RACF99

[Jesse 1 Robinson]

Thanks. I confirmed with the person who asked me that this is indeed the RACF99 
in question. Good to go.  

.
.
.
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 Skeldum, William
Sent: Wednesday, June 01, 2016 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF99

This site lists a RACF99 utility for certificates.
http://www.nigelpentland.co.uk/readme.htm
Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, June 01, 2016 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF99

I know that this question should go to RACF-L, but I cannot seem to get their 
email posts into my inbox. I've been asked to pursue the 'RACF99 utility' to 
query the status of certificates. I've Googled the heck out of that name but 
cannot find any official (IBM) doc. Could someone point me in the right 
direction? Thanks.

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

[Skeldum, William]

This site lists a RACF99 utility for certificates.
http://www.nigelpentland.co.uk/readme.htm
Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, June 01, 2016 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF99

I know that this question should go to RACF-L, but I cannot seem to get their 
email posts into my inbox. I've been asked to pursue the 'RACF99 utility' to 
query the status of certificates. I've Googled the heck out of that name but 
cannot find any official (IBM) doc. Could someone point me in the right 
direction? Thanks.

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: RACF99

[Pfister, Nathan]

I believe what you are looking for are the RACF utilities from www.racf.co.uk.  
Nigel Pentland has put these together.

This url to the PDF shows the documentation for the utilities: 
http://www.racf.co.uk/racf.pdf (I think this is an older version but still 
relevant).

RACF99 is part of this utility suite.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, June 01, 2016 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF99

I know that this question should go to RACF-L, but I cannot seem to get their 
email posts into my inbox. I've been asked to pursue the 'RACF99 utility' to 
query the status of certificates. I've Googled the heck out of that name but 
cannot find any official (IBM) doc. Could someone point me in the right 
direction? Thanks.

.
.
.
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
E-MAIL CONFIDENTIALITY NOTICE: This e-mail from Donegal Insurance Group may 
contain CONFIDENTIAL and legally protected information. If you are not an 
intended recipient, please do not copy, use or disclose this email or its 
contents to others; and please notify us by calling toll free (800) 877-0600 
x7880 or by replying to this message, and then delete it from your system. 
Delivery of this email to an unintended recipient is not a waiver of any 
attorney-client or other applicable privilege.

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

RACF99

[Jesse 1 Robinson]

I know that this question should go to RACF-L, but I cannot seem to get their 
email posts into my inbox. I've been asked to pursue the 'RACF99 utility' to 
query the status of certificates. I've Googled the heck out of that name but 
cannot find any official (IBM) doc. Could someone point me in the right 
direction? Thanks.

.
.
.
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: Migration to Enterprise COBOL V5.2

[Salva Carrasco]

- Test(DWARF): Increase size in library but not in memory, debug data is only 
loaded at error/abend time.
- Best CPU usage if using Arch(9/10) on execution.
- Worst compile CPU/Time/Storage. REGION=0M, IEFUSI, ...
- Take an eye on latest maintenance, specially LE.
- Be aware of Arch level for your BRS site.
- Be aware of CANCEL sentence for mixed 4.2 & 5.2 Cobol load modules.
. Be aware of STRING sentence when using same source & target data field.
- Be aware of low-values decimal zones. IF FIELD = ZERO, false for 4.2, true 
for 5.2. Look at ZONEDATA *new* option.

Good look.

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

Re: Migration to Enterprise COBOL V5.2

[Mike Schwab]

No change in coding.  Change in placement of object code.

On Wed, Jun 1, 2016 at 11:49 AM, Itschak Mugzach  wrote:
> Sure. Less cup and much more manual work when a subroutine is updated...
>
> ITschak
>
> נשלח מה-iPad שלי
>
> ‫ב-1 ביוני 2016, בשעה 19:44, ‏‏Mike Schwab ‏ כתב/ה:‬
>
>> Increase in size would indicate small subroutines converted to
>> instream code.  Branches are expensive, so more core means faster /
>> less CPU programs, at expense of more memory / I/O.
>>
>>> On Wed, Jun 1, 2016 at 11:40 AM, Paul Strauss  wrote:
>>> My customer wants to start the migration to Enterprise COBOL V5.2. I know
>>> V6.1 is out but we need to get going on this project. I have deleted all
>>> COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked
>>> with an applications representative and they have decided on the compiler
>>> options they want. Load library conversion to PDSE is complete. Analysis
>>> of load libraries looking for OS/VS COBOL and determining which of those
>>> load modules are still in use has been determined and they will be
>>> recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are
>>> some others things to look at but these are done.
>>>
>>> If there is a COBOL specific web site for these types of questions that
>>> would be a better place for these questions please let me know.
>>>
>>> Some users have been playing with the new compiler and comparing it with
>>> Enterprise COBOL V4.2. They have picked a few current programs and
>>> compiled, linked and run them. One load module was 3-4 times as big when
>>> compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical
>>> increase in size for V5.2 compiles?
>>>
>>> Has anyone noticed a difference in CPU execution time either way?
>>>
>>> A size increase would not be a big problem but a large increase in CPU
>>> time would be.
>>>
>>> Thank You,
>>>
>>> Paul Strauss
>>>
>>> IBM Global Services
>>> z/OS MVS and Program Products
>>> Department F2VE
>>> 150 Kettletown Rd.
>>> Southbury, CT 06488
>>> (203) 272-2758
>>> strau...@us.ibm.com
>>>
>>> NOTICE: This e-mail message and all attachments may contain confidential
>>> information intended solely for the use of the addressee. If you are not
>>> the intended recipient, you are hereby notified that you may not read,
>>> copy, distribute or otherwise use this message or its attachments. If you
>>> have received this message in error, please notify the sender by email and
>>> delete all copies of the message immediately.
>>>
>>>
>>> --
>>> 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



-- 
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: Migration to Enterprise COBOL V5.2

[Frank Swarbrick]

Do you compile with the TEST option?  If you used TEST(SEPARATE) before and 
just use TEST now, then before your debug information was in a separate file, 
and now its included as a NOLOAD section of the executable program object.

Or it could be something else.  :-)
> Date: Wed, 1 Jun 2016 12:40:42 -0400
> From: strau...@us.ibm.com
> Subject: Migration to Enterprise COBOL V5.2
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> My customer wants to start the migration to Enterprise COBOL V5.2. I know 
> V6.1 is out but we need to get going on this project. I have deleted all 
> COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked 
> with an applications representative and they have decided on the compiler 
> options they want. Load library conversion to PDSE is complete. Analysis 
> of load libraries looking for OS/VS COBOL and determining which of those 
> load modules are still in use has been determined and they will be 
> recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are 
> some others things to look at but these are done. 
> 
> If there is a COBOL specific web site for these types of questions that 
> would be a better place for these questions please let me know.
> 
> Some users have been playing with the new compiler and comparing it with 
> Enterprise COBOL V4.2. They have picked a few current programs and 
> compiled, linked and run them. One load module was 3-4 times as big when 
> compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical 
> increase in size for V5.2 compiles?
> 
> Has anyone noticed a difference in CPU execution time either way?
> 
> A size increase would not be a big problem but a large increase in CPU 
> time would be.
> 
> Thank You,
> 
> Paul Strauss
> 
> IBM Global Services
> z/OS MVS and Program Products 
> Department F2VE
> 150 Kettletown Rd.
> Southbury, CT 06488
> (203) 272-2758 
> strau...@us.ibm.com
> 
> NOTICE: This e-mail message and all attachments may contain confidential 
> information intended solely for the use of the addressee. If you are not 
> the intended recipient, you are hereby notified that you may not read, 
> copy, distribute or otherwise use this message or its attachments. If you 
> have received this message in error, please notify the sender by email and 
> delete all copies of the message immediately.
> 
> 
> --
> 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: Migration to Enterprise COBOL V5.2

[Itschak Mugzach]

Sure. Less cup and much more manual work when a subroutine is updated...

ITschak

נשלח מה-iPad שלי

‫ב-1 ביוני 2016, בשעה 19:44, ‏‏Mike Schwab ‏ כתב/ה:‬

> Increase in size would indicate small subroutines converted to
> instream code.  Branches are expensive, so more core means faster /
> less CPU programs, at expense of more memory / I/O.
> 
>> On Wed, Jun 1, 2016 at 11:40 AM, Paul Strauss  wrote:
>> My customer wants to start the migration to Enterprise COBOL V5.2. I know
>> V6.1 is out but we need to get going on this project. I have deleted all
>> COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked
>> with an applications representative and they have decided on the compiler
>> options they want. Load library conversion to PDSE is complete. Analysis
>> of load libraries looking for OS/VS COBOL and determining which of those
>> load modules are still in use has been determined and they will be
>> recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are
>> some others things to look at but these are done.
>> 
>> If there is a COBOL specific web site for these types of questions that
>> would be a better place for these questions please let me know.
>> 
>> Some users have been playing with the new compiler and comparing it with
>> Enterprise COBOL V4.2. They have picked a few current programs and
>> compiled, linked and run them. One load module was 3-4 times as big when
>> compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical
>> increase in size for V5.2 compiles?
>> 
>> Has anyone noticed a difference in CPU execution time either way?
>> 
>> A size increase would not be a big problem but a large increase in CPU
>> time would be.
>> 
>> Thank You,
>> 
>> Paul Strauss
>> 
>> IBM Global Services
>> z/OS MVS and Program Products
>> Department F2VE
>> 150 Kettletown Rd.
>> Southbury, CT 06488
>> (203) 272-2758
>> strau...@us.ibm.com
>> 
>> NOTICE: This e-mail message and all attachments may contain confidential
>> information intended solely for the use of the addressee. If you are not
>> the intended recipient, you are hereby notified that you may not read,
>> copy, distribute or otherwise use this message or its attachments. If you
>> have received this message in error, please notify the sender by email and
>> delete all copies of the message immediately.
>> 
>> 
>> --
>> 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: Migration to Enterprise COBOL V5.2

[Mike Schwab]

Increase in size would indicate small subroutines converted to
instream code.  Branches are expensive, so more core means faster /
less CPU programs, at expense of more memory / I/O.

On Wed, Jun 1, 2016 at 11:40 AM, Paul Strauss  wrote:
> My customer wants to start the migration to Enterprise COBOL V5.2. I know
> V6.1 is out but we need to get going on this project. I have deleted all
> COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked
> with an applications representative and they have decided on the compiler
> options they want. Load library conversion to PDSE is complete. Analysis
> of load libraries looking for OS/VS COBOL and determining which of those
> load modules are still in use has been determined and they will be
> recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are
> some others things to look at but these are done.
>
> If there is a COBOL specific web site for these types of questions that
> would be a better place for these questions please let me know.
>
> Some users have been playing with the new compiler and comparing it with
> Enterprise COBOL V4.2. They have picked a few current programs and
> compiled, linked and run them. One load module was 3-4 times as big when
> compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical
> increase in size for V5.2 compiles?
>
> Has anyone noticed a difference in CPU execution time either way?
>
> A size increase would not be a big problem but a large increase in CPU
> time would be.
>
> Thank You,
>
> Paul Strauss
>
> IBM Global Services
> z/OS MVS and Program Products
> Department F2VE
> 150 Kettletown Rd.
> Southbury, CT 06488
> (203) 272-2758
> strau...@us.ibm.com
>
> NOTICE: This e-mail message and all attachments may contain confidential
> information intended solely for the use of the addressee. If you are not
> the intended recipient, you are hereby notified that you may not read,
> copy, distribute or otherwise use this message or its attachments. If you
> have received this message in error, please notify the sender by email and
> delete all copies of the message immediately.
>
>
> --
> 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

Migration to Enterprise COBOL V5.2

[Paul Strauss]

My customer wants to start the migration to Enterprise COBOL V5.2. I know 
V6.1 is out but we need to get going on this project. I have deleted all 
COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked 
with an applications representative and they have decided on the compiler 
options they want. Load library conversion to PDSE is complete. Analysis 
of load libraries looking for OS/VS COBOL and determining which of those 
load modules are still in use has been determined and they will be 
recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are 
some others things to look at but these are done. 

If there is a COBOL specific web site for these types of questions that 
would be a better place for these questions please let me know.

Some users have been playing with the new compiler and comparing it with 
Enterprise COBOL V4.2. They have picked a few current programs and 
compiled, linked and run them. One load module was 3-4 times as big when 
compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical 
increase in size for V5.2 compiles?

Has anyone noticed a difference in CPU execution time either way?

A size increase would not be a big problem but a large increase in CPU 
time would be.

Thank You,

Paul Strauss

IBM Global Services
z/OS MVS and Program Products 
Department F2VE
150 Kettletown Rd.
Southbury, CT 06488
(203) 272-2758 
strau...@us.ibm.com

NOTICE: This e-mail message and all attachments may contain confidential 
information intended solely for the use of the addressee. If you are not 
the intended recipient, you are hereby notified that you may not read, 
copy, distribute or otherwise use this message or its attachments. If you 
have received this message in error, please notify the sender by email and 
delete all copies of the message immediately.


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

Re: TCPIP Help

[Mike Schwab]

You can run $INDFILE with the bottom half on ISPF 6 (Command input).

On Wed, Jun 1, 2016 at 9:42 AM, John McKown
 wrote:
> On Wed, Jun 1, 2016 at 9:21 AM, Scott Ford  wrote:
>
>> All:
>>
>> I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT and have
>> a wierd issue. I am trying to send a file via IND$FILE, I see the xref
>> start and it hangs forever forcing me to cancel the TSO userid. Could this
>> be a IP routing issue ?  I need some help on where to start looking.  I
>> realize this isnt the TCPIP forum and apologize for the thread.but I need
>> some help.
>>
>
> I'm confused. IND$FILE does not run on TCP/IP per se. It runs over the
> 3270 data stream (the 3270 emulation session). So long as you can access
> TSO with no problems, then IND$FILE should work OK. How are you invoking
> IND$FILE? In the past, I would get out of ISPF, back to the TSO ready. I
> then switched to a command prompt and used the "send" or "receive" (IIRC)
> commands, which were a part of the 3270 emulation software package.
>
> One thing that I know of which will hang up an IND$FILE will be an
> asynchronous message coming to the TSO user, such as from a NOTIFY on a
> job or someone using the TSO SEND command to send a message. I always used
> a PROFILE NOINTERCOM to help avoid this problem.
>
>
>
>
>>
>> Regards,
>> Scott
>>
>>
>
>
> --
> The unfacts, did we have them, are too imprecisely few to warrant our
> certitude.
>
> Maranatha! <><
> John McKown
>
> --
> 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: TCPIP Help

[Jesse 1 Robinson]

Advantages of IND$FILE:

-- Quick. I can usually complete a (small) file transfer in less time than it 
takes to get past FTP syntax complaints.
-- Simple. My emulator (Vista3270) has built-in support for IND$FILE. Just 
click Up arrow or Down arrow. 
-- I can initiate up or download from my host session. FTP has to be initiated 
from the work station because it has no FTP server.

So for short ad hoc transfers, I usually use IND$FILE. For big files or 
repetitive/canned processes, FTP is preferable. Or if security is required. 

.
.
.
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 Rugen, Len
Sent: Wednesday, June 01, 2016 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TCPIP Help

It can be the case of old dogs not learning new tricks, I still use rz and sz, 
I always have to install lrzsz first, that's one of my footprints that I've 
been on a system :-)  

Len Rugen

Metrics and Automation – umdoitmetr...@missouri.edu



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Shorkend
Sent: Wednesday, June 01, 2016 10:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCPIP Help

Mainly out of curiosity, why use IND$FILE and not FTP?
I am assuming that TCPIP is up and running and that you are not accessing your 
TSO via native VTAM?

On 1 June 2016 at 17:52, Rugen, Len  wrote:

> I've seen similar problems where some point along the path fumbles 
> max-MTU sized packets.
>
> You can test this by setting the MTU on the PC initiating the TSO 
> session to something smaller, try 1200, it's usually just a small 
> amount smaller size MTU that works.
>
> 3270 screen sessions will work as long as they don't try to send a max 
> MTU frame, but IND$FILE will almost guarantee a max MTU frame.
>
> Len Rugen
>
> Metrics and Automation – umdoitmetr...@missouri.edu
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John McKown
> Sent: Wednesday, June 01, 2016 9:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TCPIP Help
>
> On Wed, Jun 1, 2016 at 9:21 AM, Scott Ford  wrote:
>
> > All:
> >
> > I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT 
> > and have a wierd issue. I am trying to send a file via IND$FILE, I 
> > see the xref start and it hangs forever forcing me to cancel the TSO userid.
> > Could this be a IP routing issue ?  I need some help on where to 
> > start looking.  I realize this isnt the TCPIP forum and apologize 
> > for the thread.but I need some help.
> >
>
> ​I'm confused. IND$FILE does not run on TCP/IP per se. It runs over 
> the
> 3270 data stream (the 3270 emulation session). So long as you can 
> access TSO with no problems, then IND$FILE should work OK. ​How are 
> you invoking IND$FILE? In the past, I would get out of ISPF, back to 
> the TSO ready. I then switched to a command prompt and used the "send"
> or "receive" (IIRC) commands, which were a part of the 3270 emulation 
> software package.
>
> ​One thing that I know of which will hang up an IND$FILE will be an 
> asynchronous message coming to the ​TSO user, such as from a NOTIFY on 
> a job or someone using the TSO SEND command to send a message. I 
> always used a PROFILE NOINTERCOM to help avoid this problem.
>
>
>
>
> >
> > Regards,
> > Scott
> >
> >
>
>
> --
> The unfacts, did we have them, are too imprecisely few to warrant our 
> certitude.
>
> 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
>



--
Mike Shorkend
m...@shorkend.com
www.shorkend.com
Tel: +972524208743
Fax: +97239772196

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

Re: LARGEDS and Z11 Mode

[Staller, Allan]

I did not have any issues, so I never needed to do this.



Anybody have issues restoring jobs offloaded to tape that are z2 mode after 
going to z11 mode?



This email � including attachments � may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: LARGEDS and Z11 Mode

[Staller, Allan]

Agreed!


Allen, Oops wanted to include this into the original post. Appears to me there 
should be plenty of free records here? The increase I believe is 302? Thanks 
Matt

$HASP852 CKPTSPACE
$HASP852 CKPTSPACE  BERTNUM=32100,BERTFREE=31657,BERTWARN=80, 
$HASP852CKPT1=(CAPACITY=6288,UNUSED=4446),CKPT2=()

$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895  -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895  -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895  -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895  -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895  -- LARGEDS SUPPORT MUST BE ACTIVATED.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: Wednesday, June 01, 2016 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LARGEDS and Z11 Mode

Should do it. 

I presume this will occur on the z/OS 1.13 system prior to the upgrade.

$TSPOOLDEF should present no issues.

At z/OS 1.13 you can issue $DACTIVATE, LEVEL=Z2 to "backout the upgrade. This 
*IS NOT* available on z/OS 2.2. 

Z11 mode has been out for such a long time that I cannot forsee any issues at 
this point in time. 

You *MIGHT* consider enlarging the checkpoint dataset based on  "$HASP895  -- 
EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.".  I can't be certain without seeing 
the O/P of $DCHKPTSPACE.

HTH,



Planning for z1.13 to 2.2 upgrade and found that we need to move to jes2 
checkpoint mode Z11. We are a monplex so no MAS to be concerned about. I gather 
from reading the jes2 init and tuning, Reference guide and JES2 Performance and 
Availability Considerations in Redbooks the following.

Use $DACTIVATE command and resolve outstanding requirements, for me that looks 
like moving to LARGEDS support.
Change SPOOLDEF, LARGEDS=ALLOWED ($T SPOOLDEF,LARGEDS=ALLOWED) Issue $ACTIVE

Did I miss any steps? thanks Matt

This would be done during a scheduled system outage so there would be no 
activity.

What I can't find is how to test afterward, what problems to look for, how to 
back out if necessary?

Below is the display of the jes dactivate.
$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895  -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895  -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895  -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895  -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895  -- LARGEDS SUPPORT MUST BE ACTIVATED.


This email – including attachments – may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: LARGEDS and Z11 Mode

[Dazzo, Matt]

Anybody have issues restoring jobs offloaded to tape that are z2 mode after 
going to z11 mode?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Purdy
Sent: Wednesday, June 01, 2016 11:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LARGEDS and Z11 Mode

Matt, I did a $DCKPTSPACE before and after the $ACTIVATE just to review. Added 
the parameter BERTUSE on a second $DCKPTSPACE command to insure no calculation 
errors and a second review. I believe the JOE count changed, but there may have 
been other spool activity going on.

Also $PJES2,ABEND and restarted JES to verify JES would work while I was logged 
on and able to fix it.

David



On Wednesday, June 1, 2016 Dazzo, Matt 
<00a854d4f854-dmarc-requ...@listserv.ua.edu> wrote:
Allen, Oops wanted to include this into the original post. Appears to me there 
should be plenty of free records here? The increase I believe is 302? Thanks 
Matt

$HASP852 CKPTSPACE
$HASP852 CKPTSPACE BERTNUM=32100,BERTFREE=31657,BERTWARN=80,
$HASP852 CKPT1=(CAPACITY=6288,UNUSED=4446),CKPT2=() 

$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895 -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895 -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895 -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895 -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895 -- LARGEDS SUPPORT MUST BE ACTIVATED.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: Wednesday, June 01, 2016 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LARGEDS and Z11 Mode

Should do it. 

I presume this will occur on the z/OS 1.13 system prior to the upgrade.

$TSPOOLDEF should present no issues.

At z/OS 1.13 you can issue $DACTIVATE, LEVEL=Z2 to "backout the upgrade. This 
*IS NOT* available on z/OS 2.2. 

Z11 mode has been out for such a long time that I cannot forsee any issues at 
this point in time. 

You *MIGHT* consider enlarging the checkpoint dataset based on "$HASP895 -- 
EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.". I can't be certain without seeing 
the O/P of $DCHKPTSPACE.

HTH,



Planning for z1.13 to 2.2 upgrade and found that we need to move to jes2 
checkpoint mode Z11. We are a monplex so no MAS to be concerned about. I gather 
from reading the jes2 init and tuning, Reference guide and JES2 Performance and 
Availability Considerations in Redbooks the following.

Use $DACTIVATE command and resolve outstanding requirements, for me that looks 
like moving to LARGEDS support.
Change SPOOLDEF, LARGEDS=ALLOWED ($T SPOOLDEF,LARGEDS=ALLOWED) Issue $ACTIVE

Did I miss any steps? thanks Matt

This would be done during a scheduled system outage so there would be no 
activity.

What I can't find is how to test afterward, what problems to look for, how to 
back out if necessary?

Below is the display of the jes dactivate.
$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895 -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895 -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895 -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895 -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895 -- LARGEDS SUPPORT MUST BE ACTIVATED.

This email ? including attachments ? may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

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

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

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

Re: LARGEDS and Z11 Mode

[David Purdy]

Matt, I did a $DCKPTSPACE before and after the $ACTIVATE just to review. Added 
the parameter BERTUSE on a second $DCKPTSPACE command to insure no calculation 
errors and a second review. I believe the JOE count changed, but there may have 
been other spool activity going on.

Also $PJES2,ABEND and restarted JES to verify JES would work while I was logged 
on and able to fix it.

David



On Wednesday, June 1, 2016 Dazzo, Matt 
<00a854d4f854-dmarc-requ...@listserv.ua.edu> wrote:
Allen, Oops wanted to include this into the original post. Appears to me there 
should be plenty of free records here? The increase I believe is 302? Thanks 
Matt

$HASP852 CKPTSPACE 
$HASP852 CKPTSPACE BERTNUM=32100,BERTFREE=31657,BERTWARN=80, 
$HASP852 CKPT1=(CAPACITY=6288,UNUSED=4446),CKPT2=() 

$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895 -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895 -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895 -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895 -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895 -- LARGEDS SUPPORT MUST BE ACTIVATED.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: Wednesday, June 01, 2016 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LARGEDS and Z11 Mode

Should do it. 

I presume this will occur on the z/OS 1.13 system prior to the upgrade.

$TSPOOLDEF should present no issues.

At z/OS 1.13 you can issue $DACTIVATE, LEVEL=Z2 to "backout the upgrade. This 
*IS NOT* available on z/OS 2.2. 

Z11 mode has been out for such a long time that I cannot forsee any issues at 
this point in time. 

You *MIGHT* consider enlarging the checkpoint dataset based on "$HASP895 -- 
EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.". I can't be certain without seeing 
the O/P of $DCHKPTSPACE.

HTH,



Planning for z1.13 to 2.2 upgrade and found that we need to move to jes2 
checkpoint mode Z11. We are a monplex so no MAS to be concerned about. I gather 
from reading the jes2 init and tuning, Reference guide and JES2 Performance and 
Availability Considerations in Redbooks the following.

Use $DACTIVATE command and resolve outstanding requirements, for me that looks 
like moving to LARGEDS support.
Change SPOOLDEF, LARGEDS=ALLOWED ($T SPOOLDEF,LARGEDS=ALLOWED) Issue $ACTIVE

Did I miss any steps? thanks Matt

This would be done during a scheduled system outage so there would be no 
activity.

What I can't find is how to test afterward, what problems to look for, how to 
back out if necessary?

Below is the display of the jes dactivate.
$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895 -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895 -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895 -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895 -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895 -- LARGEDS SUPPORT MUST BE ACTIVATED.

This email ? including attachments ? may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

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

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

Re: TCPIP Help

[Rugen, Len]

It can be the case of old dogs not learning new tricks, I still use rz and sz, 
I always have to install lrzsz first, that's one of my footprints that I've 
been on a system :-)  

Len Rugen

Metrics and Automation – umdoitmetr...@missouri.edu



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Shorkend
Sent: Wednesday, June 01, 2016 10:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCPIP Help

Mainly out of curiosity, why use IND$FILE and not FTP?
I am assuming that TCPIP is up and running and that you are not accessing your 
TSO via native VTAM?

On 1 June 2016 at 17:52, Rugen, Len  wrote:

> I've seen similar problems where some point along the path fumbles 
> max-MTU sized packets.
>
> You can test this by setting the MTU on the PC initiating the TSO 
> session to something smaller, try 1200, it's usually just a small 
> amount smaller size MTU that works.
>
> 3270 screen sessions will work as long as they don't try to send a max 
> MTU frame, but IND$FILE will almost guarantee a max MTU frame.
>
> Len Rugen
>
> Metrics and Automation – umdoitmetr...@missouri.edu
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John McKown
> Sent: Wednesday, June 01, 2016 9:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TCPIP Help
>
> On Wed, Jun 1, 2016 at 9:21 AM, Scott Ford  wrote:
>
> > All:
> >
> > I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT 
> > and have a wierd issue. I am trying to send a file via IND$FILE, I 
> > see the xref start and it hangs forever forcing me to cancel the TSO userid.
> > Could this be a IP routing issue ?  I need some help on where to 
> > start looking.  I realize this isnt the TCPIP forum and apologize 
> > for the thread.but I need some help.
> >
>
> ​I'm confused. IND$FILE does not run on TCP/IP per se. It runs over 
> the
> 3270 data stream (the 3270 emulation session). So long as you can 
> access TSO with no problems, then IND$FILE should work OK. ​How are 
> you invoking IND$FILE? In the past, I would get out of ISPF, back to 
> the TSO ready. I then switched to a command prompt and used the "send" 
> or "receive" (IIRC) commands, which were a part of the 3270 emulation 
> software package.
>
> ​One thing that I know of which will hang up an IND$FILE will be an 
> asynchronous message coming to the ​TSO user, such as from a NOTIFY on 
> a job or someone using the TSO SEND command to send a message. I 
> always used a PROFILE NOINTERCOM to help avoid this problem.
>
>
>
>
> >
> > Regards,
> > Scott
> >
> >
>
>
> --
> The unfacts, did we have them, are too imprecisely few to warrant our 
> certitude.
>
> 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
>



--
Mike Shorkend
m...@shorkend.com
www.shorkend.com
Tel: +972524208743
Fax: +97239772196

--
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: TCPIP Help

[Mike Shorkend]

Mainly out of curiosity, why use IND$FILE and not FTP?
I am assuming that TCPIP is up and running and that you are not accessing
your TSO via native VTAM?

On 1 June 2016 at 17:52, Rugen, Len  wrote:

> I've seen similar problems where some point along the path fumbles max-MTU
> sized packets.
>
> You can test this by setting the MTU on the PC initiating the TSO session
> to something smaller, try 1200, it's usually just a small amount smaller
> size MTU that works.
>
> 3270 screen sessions will work as long as they don't try to send a max MTU
> frame, but IND$FILE will almost guarantee a max MTU frame.
>
> Len Rugen
>
> Metrics and Automation – umdoitmetr...@missouri.edu
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, June 01, 2016 9:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TCPIP Help
>
> On Wed, Jun 1, 2016 at 9:21 AM, Scott Ford  wrote:
>
> > All:
> >
> > I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT and
> > have a wierd issue. I am trying to send a file via IND$FILE, I see the
> > xref start and it hangs forever forcing me to cancel the TSO userid.
> > Could this be a IP routing issue ?  I need some help on where to start
> > looking.  I realize this isnt the TCPIP forum and apologize for the
> > thread.but I need some help.
> >
>
> ​I'm confused. IND$FILE does not run on TCP/IP per se. It runs over the
> 3270 data stream (the 3270 emulation session). So long as you can access
> TSO with no problems, then IND$FILE should work OK. ​How are you invoking
> IND$FILE? In the past, I would get out of ISPF, back to the TSO ready. I
> then switched to a command prompt and used the "send" or "receive" (IIRC)
> commands, which were a part of the 3270 emulation software package.
>
> ​One thing that I know of which will hang up an IND$FILE will be an
> asynchronous message coming to the ​TSO user, such as from a NOTIFY on a
> job or someone using the TSO SEND command to send a message. I always used
> a PROFILE NOINTERCOM to help avoid this problem.
>
>
>
>
> >
> > Regards,
> > Scott
> >
> >
>
>
> --
> The unfacts, did we have them, are too imprecisely few to warrant our
> certitude.
>
> 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
>



-- 
Mike Shorkend
m...@shorkend.com
www.shorkend.com
Tel: +972524208743
Fax: +97239772196

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

Re: TCPIP Help

[Edward Finnell]

I don't remember my VTAM buffer pools, but one that caught us in a couple  
migrations was IOBUF.
 
===> d net,bufruse (?) Tells the tale. What we're looking for is times  
expanded. VTAM reconfigures ifself to accommodate but freezes activity in the  
process. 
 
 
 
In a message dated 6/1/2016 9:52:53 A.M. Central Daylight Time,  
rug...@missouri.edu writes:

You can  test this by setting the MTU on the PC initiating the TSO session 
to something  smaller, try 1200, it's usually just a small amount smaller 
size MTU that  works. 

3270 screen sessions will work as long as they don't try to  send a max MTU 
frame, but IND$FILE will almost guarantee a max MTU  frame.


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

Re: LARGEDS and Z11 Mode

[Dazzo, Matt]

Allen, Oops wanted to include this into the original post. Appears to me there 
should be plenty of free records here? The increase I believe is 302? Thanks 
Matt

$HASP852 CKPTSPACE
$HASP852 CKPTSPACE  BERTNUM=32100,BERTFREE=31657,BERTWARN=80, 
$HASP852CKPT1=(CAPACITY=6288,UNUSED=4446),CKPT2=()

$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895  -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895  -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895  -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895  -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895  -- LARGEDS SUPPORT MUST BE ACTIVATED.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: Wednesday, June 01, 2016 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LARGEDS and Z11 Mode

Should do it. 

I presume this will occur on the z/OS 1.13 system prior to the upgrade.

$TSPOOLDEF should present no issues.

At z/OS 1.13 you can issue $DACTIVATE, LEVEL=Z2 to "backout the upgrade. This 
*IS NOT* available on z/OS 2.2. 

Z11 mode has been out for such a long time that I cannot forsee any issues at 
this point in time. 

You *MIGHT* consider enlarging the checkpoint dataset based on  "$HASP895  -- 
EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.".  I can't be certain without seeing 
the O/P of $DCHKPTSPACE.

HTH,



Planning for z1.13 to 2.2 upgrade and found that we need to move to jes2 
checkpoint mode Z11. We are a monplex so no MAS to be concerned about. I gather 
from reading the jes2 init and tuning, Reference guide and JES2 Performance and 
Availability Considerations in Redbooks the following.

Use $DACTIVATE command and resolve outstanding requirements, for me that looks 
like moving to LARGEDS support.
Change SPOOLDEF, LARGEDS=ALLOWED ($T SPOOLDEF,LARGEDS=ALLOWED) Issue $ACTIVE

Did I miss any steps? thanks Matt

This would be done during a scheduled system outage so there would be no 
activity.

What I can't find is how to test afterward, what problems to look for, how to 
back out if necessary?

Below is the display of the jes dactivate.
$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895  -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895  -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895  -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895  -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895  -- LARGEDS SUPPORT MUST BE ACTIVATED.

This email ? including attachments ? may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

--
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: TCPIP Help

[Rugen, Len]

I've seen similar problems where some point along the path fumbles max-MTU 
sized packets.  

You can test this by setting the MTU on the PC initiating the TSO session to 
something smaller, try 1200, it's usually just a small amount smaller size MTU 
that works. 

3270 screen sessions will work as long as they don't try to send a max MTU 
frame, but IND$FILE will almost guarantee a max MTU frame.

Len Rugen

Metrics and Automation – umdoitmetr...@missouri.edu


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, June 01, 2016 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCPIP Help

On Wed, Jun 1, 2016 at 9:21 AM, Scott Ford  wrote:

> All:
>
> I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT and 
> have a wierd issue. I am trying to send a file via IND$FILE, I see the 
> xref start and it hangs forever forcing me to cancel the TSO userid. 
> Could this be a IP routing issue ?  I need some help on where to start 
> looking.  I realize this isnt the TCPIP forum and apologize for the 
> thread.but I need some help.
>

​I'm confused. IND$FILE does not run on TCP/IP per se. It runs over the
3270 data stream (the 3270 emulation session). So long as you can access TSO 
with no problems, then IND$FILE should work OK. ​How are you invoking IND$FILE? 
In the past, I would get out of ISPF, back to the TSO ready. I then switched to 
a command prompt and used the "send" or "receive" (IIRC) commands, which were a 
part of the 3270 emulation software package.

​One thing that I know of which will hang up an IND$FILE will be an 
asynchronous message coming to the ​TSO user, such as from a NOTIFY on a job or 
someone using the TSO SEND command to send a message. I always used a PROFILE 
NOINTERCOM to help avoid this problem.




>
> Regards,
> Scott
>
>


--
The unfacts, did we have them, are too imprecisely few to warrant our certitude.

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: TCPIP Help

[John McKown]

On Wed, Jun 1, 2016 at 9:21 AM, Scott Ford  wrote:

> All:
>
> I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT and have
> a wierd issue. I am trying to send a file via IND$FILE, I see the xref
> start and it hangs forever forcing me to cancel the TSO userid. Could this
> be a IP routing issue ?  I need some help on where to start looking.  I
> realize this isnt the TCPIP forum and apologize for the thread.but I need
> some help.
>

​I'm confused. IND$FILE does not run on TCP/IP per se. It runs over the
3270 data stream (the 3270 emulation session). So long as you can access
TSO with no problems, then IND$FILE should work OK. ​How are you invoking
IND$FILE? In the past, I would get out of ISPF, back to the TSO ready. I
then switched to a command prompt and used the "send" or "receive" (IIRC)
commands, which were a part of the 3270 emulation software package.

​One thing that I know of which will hang up an IND$FILE will be an
asynchronous message coming to the ​TSO user, such as from a NOTIFY on a
job or someone using the TSO SEND command to send a message. I always used
a PROFILE NOINTERCOM to help avoid this problem.




>
> Regards,
> Scott
>
>


-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: TCPIP Help

[Lizette Koehler]

Have you looked in JES syslog for messages?

Have you run traces in Vtam/TCPIP?

I am not sure there is enough info to begin to guess.

Have you run traces from your terminal emulator?

Are you using a session manager?  If so, have you run traces there?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Scott Ford
> Sent: Wednesday, June 01, 2016 7:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TCPIP Help
> 
> All:
> 
> I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT and have a
> wierd issue. I am trying to send a file via IND$FILE, I see the xref start and
> it hangs forever forcing me to cancel the TSO userid. Could this be a IP
> routing issue ?  I need some help on where to start looking.  I realize this
> isnt the TCPIP forum and apologize for the thread.but I need some help.
> 
> Regards,
> Scott
> 

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

Re: LARGEDS and Z11 Mode

[David Purdy]

Backout is to $ACTIVATE,LEVEL=Z2
which is the 2.1 $ACTIVATE default.  We set LARGEDS=ALLOWED 

Just went through this, and it took 3 seconds wall time in a large sysplex.

David



On Wednesday, June 1, 2016 Dazzo, Matt 
<00a854d4f854-dmarc-requ...@listserv.ua.edu> wrote:
Planning for z1.13 to 2.2 upgrade and found that we need to move to jes2 
checkpoint mode Z11. We are a monplex so no
MAS to be concerned about. I gather from reading the jes2 init and tuning, 
Reference guide and JES2 Performance and Availability Considerations in 
Redbooks the following.

Use $DACTIVATE command and resolve outstanding requirements, for me that looks 
like moving to LARGEDS support.
Change SPOOLDEF, LARGEDS=ALLOWED ($T SPOOLDEF,LARGEDS=ALLOWED)
Issue $ACTIVE

Did I miss any steps? thanks Matt

This would be done during a scheduled system outage so there would be no 
activity.

What I can't find is how to test afterward, what problems to look for, how to 
back out if necessary?

Below is the display of the jes dactivate.
$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895 -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895 -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895 -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895 -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895 -- LARGEDS SUPPORT MUST BE ACTIVATED.

--
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: TCPIP Help

[Staller, Allan]

Try enlarging your TSO region. IND$FILE (AFAIK) does not use TCP/IP for 
communication. It seems to be a screen scraper.

HTH,


I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT and have a 
wierd issue. I am trying to send a file via IND$FILE, I see the xref start and 
it hangs forever forcing me to cancel the TSO userid. Could this be a IP 
routing issue ?  I need some help on where to start looking.  I realize this 
isnt the TCPIP forum and apologize for the thread.but I need some help.


This email � including attachments � may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: LARGEDS and Z11 Mode

[Staller, Allan]

Should do it. 

I presume this will occur on the z/OS 1.13 system prior to the upgrade.

$TSPOOLDEF should present no issues.

At z/OS 1.13 you can issue $DACTIVATE, LEVEL=Z2 to "backout the upgrade. This 
*IS NOT* available on z/OS 2.2. 

Z11 mode has been out for such a long time that I cannot forsee any issues at 
this point in time. 

You *MIGHT* consider enlarging the checkpoint dataset based on  "$HASP895  -- 
EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.".  I can't be certain without seeing 
the O/P of $DCHKPTSPACE.

HTH,



Planning for z1.13 to 2.2 upgrade and found that we need to move to jes2 
checkpoint mode Z11. We are a monplex so no MAS to be concerned about. I gather 
from reading the jes2 init and tuning, Reference guide and JES2 Performance and 
Availability Considerations in Redbooks the following.

Use $DACTIVATE command and resolve outstanding requirements, for me that looks 
like moving to LARGEDS support.
Change SPOOLDEF, LARGEDS=ALLOWED ($T SPOOLDEF,LARGEDS=ALLOWED) Issue $ACTIVE

Did I miss any steps? thanks Matt

This would be done during a scheduled system outage so there would be no 
activity.

What I can't find is how to test afterward, what problems to look for, how to 
back out if necessary?

Below is the display of the jes dactivate.
$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895  -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895  -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895  -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895  -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895  -- LARGEDS SUPPORT MUST BE ACTIVATED.

This email – including attachments – may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: TCPIP Help

[michelbutz]

Can I ask you another question did you get z/OS 
2.2 from zpdt  as I am still waiting 

Thanks 

Sent from my iPhone

> On Jun 1, 2016, at 10:21 AM, Scott Ford  wrote:
> 
> All:
> 
> I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT and have
> a wierd issue. I am trying to send a file via IND$FILE, I see the xref
> start and it hangs forever forcing me to cancel the TSO userid. Could this
> be a IP routing issue ?  I need some help on where to start looking.  I
> realize this isnt the TCPIP forum and apologize for the thread.but I need
> some help.
> 
> Regards,
> Scott
> 
> --
> 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

TCPIP Help

[Scott Ford]

All:

I need some help guys/gals.  I have installed z/OS 2.2 under z/PDT and have
a wierd issue. I am trying to send a file via IND$FILE, I see the xref
start and it hangs forever forcing me to cancel the TSO userid. Could this
be a IP routing issue ?  I need some help on where to start looking.  I
realize this isnt the TCPIP forum and apologize for the thread.but I need
some help.

Regards,
Scott

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

Re: LARGEDS and Z11 Mode

[Jousma, David]

Well, we were already at Z11 mode, and post 2.2 you can go to Z22 mode to get 
the new JES features.   One of the pre-req's to get there is 
CYL_MANAGED=ALLOWED.   We had that turned off.   Turned it on dynamically in my 
TECH environment and instantly all of my Roscoe users were unable to view any 
JES output created after turning it on, and worse yet, turning it back off, the 
output was still unable to be accessed from Roscoe.   CA is still working on 
fixes.   And, as an FYI, CYL_MANAGED=ALLOWED came along in z/OS 1.11.   As an 
aside, our spool is all mod-54's, and could be part of the reason why CA has 
had a hard time replicating the problem on their end.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dazzo, Matt
Sent: Wednesday, June 01, 2016 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LARGEDS and Z11 Mode

Planning for z1.13 to 2.2 upgrade and found that we need to move to jes2 
checkpoint mode Z11. We are a monplex so no MAS to be concerned about. I gather 
from reading the jes2 init and tuning, Reference guide and JES2 Performance and 
Availability Considerations in Redbooks the following.

Use $DACTIVATE command and resolve outstanding requirements, for me that looks 
like moving to LARGEDS support.
Change SPOOLDEF, LARGEDS=ALLOWED ($T SPOOLDEF,LARGEDS=ALLOWED) Issue $ACTIVE

Did I miss any steps? thanks Matt

This would be done during a scheduled system outage so there would be no 
activity.

What I can't find is how to test afterward, what problems to look for, how to 
back out if necessary?

Below is the display of the jes dactivate.
$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895  -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895  -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895  -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895  -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895  -- LARGEDS SUPPORT MUST BE ACTIVATED.

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

LARGEDS and Z11 Mode

[Dazzo, Matt]

Planning for z1.13 to 2.2 upgrade and found that we need to move to jes2 
checkpoint mode Z11. We are a monplex so no
MAS to be concerned about. I gather from reading the jes2 init and tuning, 
Reference guide and JES2 Performance and Availability Considerations in 
Redbooks the following.

Use $DACTIVATE command and resolve outstanding requirements, for me that looks 
like moving to LARGEDS support.
Change SPOOLDEF, LARGEDS=ALLOWED ($T SPOOLDEF,LARGEDS=ALLOWED)
Issue $ACTIVE

Did I miss any steps? thanks Matt

This would be done during a scheduled system outage so there would be no 
activity.

What I can't find is how to test afterward, what problems to look for, how to 
back out if necessary?

Below is the display of the jes dactivate.
$HASP895 $DACTIVATE 997
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895  -- CONTAINS 32100 BERTS AND BERT UTILIZATION IS 1
$HASP895 PERCENT.
$HASP895  -- CONTAINS 1847 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895  -- EXPAND CHECKPOINT SIZE TO 2149 4K RECORDS.
$HASP895  -- REQUIRE 0 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 1 PERCENT.
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895  -- LARGEDS SUPPORT MUST BE ACTIVATED.

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

Re: TSO receive on MultiVolume PS error

[Field, Alan]

 Been using this mod for years and never had an issue. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 31, 2016 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO receive on MultiVolume PS error

On Tue, 31 May 2016 09:54:22 +, Field, Alan wrote:

>Blksize 3120 is hardcoded. This usermod removes that restriction:
>
>++ USERMOD (LM00062) REWORK(2016003) 
> /* TRANSMIT OUTDA() FORCES THE BLKSIZE OF THE OUTPUT DATA SET   
>TO 3120 (X'0C30').   
>THIS MOD SETS IT TO 0 (SYSTEM DETERMINED BLKSIZE).   
>INMXM IS IN SYS1.LINKLIB.
> */ .
>++ VER (Z038) FMID(HTE77A0)  
>.
>++ ZAP (INMXM) . 
> NAME INMXM  
>  VER 1AC4 ,0C30 
>  REP 1AC4 , 
> 
Clever.  I'll assume QSAM cheerfully deals with whatever BLKSIZE SDB selects.
Is RECEIVE equally happy with it?

But doesn't it still corrupt RECFM or LRECL of an existing data set?

Is the performance gain significant with modern DASD?  I'd care more for 
preserving RECFM and LRECL, even at the cost of TRANSMIT's failing.

-- gil

--
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 are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the named addressee you must not disseminate, distribute or copy 
this e-mail. Please notify the sender immediately by e-mail if you have 
received this e-mail 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: OA49422

[Styles, Andy (SD EP zPlatform)]

This reminds me - some time ago, I posted a question about SMF records and 
aliases. A few people responded with the information about SMF storing that 
data in a additional field, added in (I think) z/OS 1.13. Subsequently, I've 
verified that JCL allocations do indeed record that information. 

ISPF, however, does something different - and I have an open PMR on this. The 
ISPF allocation routines (from my understanding) detect that you are attempting 
to access an alias, look up the real name in the catalog, and allocate that 
instead. The upshot is that browsing/editing/viewing datasets through their 
alias under ISPF fails to record the alias information in the SMF record - you 
only get the real dataset name. 

I've asked the question why, and it's apparently due to an APAR that was raised 
about 25 years ago whereby ISPF could use an incorrect dataset name. APAR was 
OY45166, which resolved several alias-related issues. OY44930 could also be 
involved. 

Just thought I'd fill you in :-)

-- 
Andy Styles 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: 27 May 2016 21:10
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: OA49422

-- This email has reached the Bank via an external source --
 

OA49422: AUTOMATIC RECALL (VIA BROWSE IN ISPF) OF A NONVSAM ALIAS FAILS WITH 
ARC1010I

Now fixed by PTF and verified.

What the APAR doesn't bother to mention is that if JCL refers to the ALIAS, HSM 
successfully recalls the data set.

I'm just curious why the behavior should be so different.  Too many paths 
through Allocation?

-- gil



Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. 
Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England 
and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered 
Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. 
Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: 
Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. 
Telephone: 0345 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Cheltenham & Gloucester plc is authorised and regulated by the Financial 
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings 
is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.


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