Re: Anyone Using MVS Bulk Data Transfer (File-to-File)?

[Timothy Sipples]

Ed Jaffe wrote:
>I didn't specify whether I was referring to the BDT SNA/NJE function
>or the BDT File-to-File function.

Clark Morris wrote:
>I think that IBM dead ended and stopped support of the File-to-file
>and all other non-JES3 related functions at least 18 years ago.

Ed Jaffe wrote:
>That's the kind of information I'm looking for, but can find no
>announcement or other reference to suggest this product isn't
>anything but 100% fully supported and fully operational.

Skip Robinson wrote:
>We considered using BDT many moons ago. NDM was the hands-down winner.
>However, BDT still appear to be supported. Still required for JES3 SNA,
>I believe.

Ed and Skip are correct. In fact, the z/OS Bulk Data Transfer (BDT) 
products are not only IBM supported but also IBM marketed. No End of 
Service date, no End of Marketing date. The 2019 z/OS 2.4 announcement 
letter included the BDT products:

https://www.ibm.com/downloads/cas/US-ENUS219-344-CA/name/US-ENUS219-344-CA.PDF

Scroll down and you'll see BDT FTF (File-to-File) listed with the 
entitlement identifier S01728V and BDT SNA NJE with the entitlement 
identifier S01728W. That means they're available for ordering even to new 
z/OS licensees.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
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: Can System REXX run Sub=MSTR ??

[Gibney, Dave]

My new shutdown automation, IS AXR. I did a loop to C AXR10 to 01, but I have 
to identify and skip the one I'm running in. 😊

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ed Jaffe
> Sent: Thursday, August 20, 2020 9:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Can System REXX run Sub=MSTR ??
> 
> On 8/20/2020 8:47 PM, Barbara Nitz wrote:
> >> Systemrexx is started automatically during IPL. What are you trying to get?
> > Not sure about the OP, but I would like to start it sub=mstr, too, just so 
> > it
> doesn't screw up JES2 shutdown every time. The dumb things (AXRxx) do
> NOT show up on a D A,L command (neither does AXR itself), so alternatively
> they SHOULD show up just to make it easier. Right now the first indication I
> get is when JES2 refuses to terminate. As far as I know, the xx can be just
> about any number, and short of having automation do contortions to find the
> correct number and then terminate the thing, I'm stuck. Besides, the AXRxx
> aren't always there. Seems to have something to do with health checker
> using system REXX.
> 
> 
> Just add a "FORCE AXR,ARM" command to your shutdown automation.
> 
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!JmP
> EgBY0HMszNaDT!5bqs_jU2w1XPWsedVkTD2EoJPQbYh_XJNmHwSPZC-
> QkANqmLxtQKXnvNedVV0g$
> 
> 
> 
> This e-mail message, including any attachments, appended messages and
> the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to
> be
> free of any virus or other defect that might affect any computer system into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
> 
> --
> 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: Can System REXX run Sub=MSTR ??

[Ed Jaffe]

On 8/20/2020 8:47 PM, Barbara Nitz wrote:

Systemrexx is started automatically during IPL. What are you trying to get?

Not sure about the OP, but I would like to start it sub=mstr, too, just so it 
doesn't screw up JES2 shutdown every time. The dumb things (AXRxx) do NOT show 
up on a D A,L command (neither does AXR itself), so alternatively they SHOULD 
show up just to make it easier. Right now the first indication I get is when 
JES2 refuses to terminate. As far as I know, the xx can be just about any 
number, and short of having automation do contortions to find the correct 
number and then terminate the thing, I'm stuck. Besides, the AXRxx aren't 
always there. Seems to have something to do with health checker using system 
REXX.



Just add a "FORCE AXR,ARM" command to your shutdown automation.


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



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: How to un-duplex a logstream?

[Barbara Nitz]

Duplexing of a log stream is a different mechanism than duplexing a structure. 

Your CFRM policy for MACK_GENERAL  needs the keyword DUPLEX(DISABLED), which is 
the default, so you need to delete the keyword DUPLEX in the CFRM policy. 
You'll need one more structure rebuild to get the new CFRM policy active.

If you don't have a copy of the CFRM policy definitions, you need to get a 
report for the policy and rebuild the policy manually. 'Setting up a sysplex' 
SA23-1399-30 has all the keywords for the CFRM policy, including a very lengthy 
DUPLEX keyword.

Keep the duplexing for the *LOGR* policy.

Regards, Barbara

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

Re: Can System REXX run Sub=MSTR ??

[Barbara Nitz]

>Systemrexx is started automatically during IPL. What are you trying to get?

Not sure about the OP, but I would like to start it sub=mstr, too, just so it 
doesn't screw up JES2 shutdown every time. The dumb things (AXRxx) do NOT show 
up on a D A,L command (neither does AXR itself), so alternatively they SHOULD 
show up just to make it easier. Right now the first indication I get is when 
JES2 refuses to terminate. As far as I know, the xx can be just about any 
number, and short of having automation do contortions to find the correct 
number and then terminate the thing, I'm stuck. Besides, the AXRxx aren't 
always there. Seems to have something to do with health checker using system 
REXX.

Regards, Barbara

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

How to un-duplex a logstream?

[Wendell Lovewell]

I'm trying to turn off duplexing in a logstream because it's driving our zPDT 
system to it's knees when we close an RLS file.

I've redefined the logstream:

LINE # CONTROL CARDS
 1 DATA TYPE(LOGR) REPORT(YES)
 2 CONTINUE
 3 DEFINE LOGSTREAM NAME(MACK.LOGSTRM)
 4STRUCTNAME(MACK_GENERAL)
 5DESCRIPTION(MACK_GENERAL_LOG)
 6DASDONLY(NO)
 7WARNPRIMARY(YES)
 8DIAG(YES)
 9 LS_DATACLAS(LOGR24K)
10 LS_SIZE(20480)
11 HLQ(LOGGER)
12 LOWOFFLOAD(0)
13 HIGHOFFLOAD(80)
14 STG_DATACLAS(LOGR4K)
15 STG_DUPLEX(NO)
16 LOGGERDUPLEX(COND)
17 RETPD(14)
18 AUTODELETE(YES)

Here's the IXCMIAPU report:

   LOGSTREAM NAME(MACK.LOGSTRM) STRUCTNAME(MACK_GENERAL) LS_DATACLAS(LOGR24K)
 LS_MGMTCLAS() LS_STORCLAS() HLQ(LOGGER) MODEL(NO) LS_SIZE(20480)
 STG_MGMTCLAS() STG_STORCLAS() STG_DATACLAS(LOGR4K) STG_SIZE(0)
 LOWOFFLOAD(0) HIGHOFFLOAD(80) STG_DUPLEX(NO) DUPLEXMODE()  <---
 RMNAME() DESCRIPTION(MACK_GENERAL_LOG) RETPD(14) AUTODELETE(YES) 
OFFLOADRECALL(YES)
 ZAI(NO) ZAIDATA('NO_ZAIDATA') WARNPRIMARY(YES) LS_ALLOCAHEAD(0)
 DASDONLY(NO) DIAG(YES) LOGGERDUPLEX(COND) <--- EHLQ(NO_EHLQ) 
GROUP(PRODUCTION)

But when I try to open a file that's defined to use MACK.LOGSTRM, it ends up 
changing it back to duplex mode after generating a couple of hundred messages, 
starting with these:

IXG117I DUPLEXING REBUILD STARTED FOR STRUCTURE MACK_GENERAL
 1 OF 1 LOGSTREAMS CONNECTED TO STRUCTURE:
 MACK.LOGSTRM

IXC571I SYSTEM-MANAGED DUPLEXING REBUILD FOR STRUCTURE
MACK_GENERAL HAS COMPLETED THE STARTUP PHASE
AND IS ENTERING THE QUIESCE PHASE.
 TIME: 08/20/2020 19:23:22.360420
 AUTO VERSION: D8668875 19A79A00

IXC571I SYSTEM-MANAGED DUPLEXING REBUILD FOR STRUCTURE
MACK_GENERAL HAS COMPLETED THE QUIESCE PHASE
AND IS ENTERING THE ALLOCATION PHASE.
 TIME: 08/20/2020 19:23:22.380045
 AUTO VERSION: D8668875 19A79A00

...and ending with:

IXG219I SYSTEM LOGGER PROCESSED TRANSITION TO DUPLEX MODE
FOR STRUCTURE MACK_GENERAL


Can someone please tell me how to disable duplexing for a logstream?  And for a 
structure, if that's a possible--I can't find any IXCMIAPU DEFINE STRUCTURE 
parameter for DUPLEX, but when I do:

D XCF,STR,STRNAME=MACK_GENERAL
IXC360I  19.55.20  DISPLAY XCF 
STRNAME: MACK_GENERAL
 STATUS: REASON SPECIFIED WITH REBUILD START:
   POLICY-INITIATED
 DUPLEXING REBUILD
   METHOD: SYSTEM-MANAGED
 AUTO VERSION: D8668875 19A79A00
   PHASE: DUPLEX ESTABLISHED <---
 EVENT MANAGEMENT: MESSAGE-BASED
 TYPE: LIST
 POLICY INFORMATION:
  POLICY SIZE: 45 M
  POLICY INITSIZE: 30 M
  POLICY MINSIZE : 0 M
  FULLTHRESHOLD  : 80
  ALLOWAUTOALT   : NO
  REBUILD PERCENT: N/A
  DUPLEX : ENABLED   <---
  ALLOWREALLOCATE: YES
  PREFERENCE LIST: CFCC1CFCC2
  ENFORCEORDER   : NO
  EXCLUSION LIST IS EMPTY   

TIA, 
Wendell

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

Re: EBCDIC and other systems

[Paul Gilmartin]

On Thu, 20 Aug 2020 17:45:09 -0400, Cameron Conacher wrote:

>I have used Japanese (930) and traditional Chinese (937) with the appropriate 
>EBCDIC Host Code Page.
>So yes DBCS is supported on a green screen
> 
Which terminals support these?

I see that on MacOS and Linux both appear in the Options menu of x3270.
I have no data to verify their operation.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.f54em00/useofr1.htm
... implies that both are among the couple dozen code pages supported
for coding Edit macros.  And, "in an Edit macro that is called from a batch
Edit session (where no terminal is attached), code page 1047 is used."

It's a pity that ISPF can't honor the CCSID in a macro tag so an author
supporting a diverse community needn't supply multiple instances of
macros for those various users.

-- gil

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

Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Seymour J Metz]

IMHO, IEFSDPPT is an anachronism and you should use SCHEDxx unless there are 
compelling reasons not to.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Thursday, August 20, 2020 11:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

My main question is which should be used?

The sysprogs over time do not always read manuals or review parmlib for 
changes.  I know this has been out there for a really long time.

I am trying to understand which is needed today.

If we should go with the LINKLIB module, what do I do to SCHEDxx - remove it 
from PARMLIB?  Not worry about it as the LINKLIB over rules the Parmlib?

The IRLM team is recommending we let LINKLIB handle this.  I can remove IRLM 
code from SCHEDxx.  But since there are other entries in SCHEDxx - I would 
prefer to do one pass rather than have to come back to this again.

So - questions
1) Who wins - LINKLIB or PARMLIB
2) Should SCHEDxx only contain OEM entries and all previous IBM Entries be 
removed
3) What is best practice

Thank you

Lizette

I didn't believe our auditor so I check, the Init and Tuning Reference page 718 
provides a list of PPT entries that are supplied by default
stated above that -
PPT
Allows the installation to specify a list of programs that require special 
attributes or to change the
attributes of the IBM-supplied default entries in the PPT (see Table 55 on page 
718). The system
scans this PPT to determine which, if any, special attributes apply to the 
program it is initiating.
Note:
1. Usually, you should not add or change programs in the program properties 
table (PPT) unless the
instructions for installing a program direct you to do so. If you do add a 
program to the PPT, or
change an existing entry's properties, ensure that the program can function 
with the properties you
have assigned to it. For example, a program designed to run in program protect 
key 8 might not be
able to run in key 10 because of hardcoded key speci®ctions in the program. If 
you were to
specify KEY(10) in this case, the program will not function correctly.
2. If the processor that your system runs on does not support program protect 
key 9, do not assign
key 9 to any programs. For speci®c processor models, see z/OS Planning for 
Installation.

I hope this helps some
Carmen

--
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: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Tom Conley]

On 8/19/2020 3:00 PM, Lizette Koehler wrote:

List -

  


I have been researching whether we need to review all of our SCHEDxx for PPT
and remove anything that is currently shipped by IBM in Linklib for IEFSDPPT

  


Does anyone have any observations on this?



I am currently working on some DB2 upgrades and it was recommended to remove
IRLM from SCHEDxx and let IEFSDPPT handle it

  


Thank you for any guidance

  


Lizette



Lizette,

I flogged Peter Relson repeatedly for years until he finally gave in and 
created the D PPT command.  It is your friend, use it.


Tom

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

Re: Anyone Using MVS Bulk Data Transfer (File-to-File)?

[Jesse 1 Robinson]

We considered using BDT many moons ago. NDM was the hands-down winner. However, 
BDT still appear to be supported. Still required for JES3 SNA, I believe.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.e0za100/e0za10007.htm

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Clark Morris
Sent: Thursday, August 20, 2020 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Anyone Using MVS Bulk Data Transfer (File-to-File)?

CAUTION EXTERNAL EMAIL

[Default] On 20 Aug 2020 13:31:43 -0700, in bit.listserv.ibm-main 
edja...@phoenixsoftware.com (Ed Jaffe) wrote:

>On 8/20/2020 1:14 PM, Clark Morris wrote:
>>
>> Any shop using SNA-NJE on JES3 needs it.  Since JES2 didn't require 
>> it for SNA-NJE, my single instance shop converted to JES2 so we saved 
>> by both not having to pay for BDT but also JES2 was cheaper.
>
>Good observation!
>
>I didn't specify whether I was referring to the BDT SNA/NJE function or 
>the BDT File-to-File function.

I think that IBM dead ended and stopped support of the File-to-file and all 
other non-JES3 related functions at least 18 years ago.

Clark Morris
>
>I was thinking of the latter...


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

Re: Anyone Using MVS Bulk Data Transfer (File-to-File)?

[Ed Jaffe]

On 8/20/2020 3:52 PM, Clark Morris wrote:


I think that IBM dead ended and stopped support of the File-to-file
and all other non-JES3 related functions at least 18 years ago.


That's the kind of information I'm looking for, but can find no 
announcement or other reference to suggest this product isn't anything 
but 100% fully supported and fully operational.


If discontinued, what was it replaced with?

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



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Anyone Using MVS Bulk Data Transfer (File-to-File)?

[Clark Morris]

[Default] On 20 Aug 2020 13:31:43 -0700, in bit.listserv.ibm-main
edja...@phoenixsoftware.com (Ed Jaffe) wrote:

>On 8/20/2020 1:14 PM, Clark Morris wrote:
>>
>> Any shop using SNA-NJE on JES3 needs it.  Since JES2 didn't require it
>> for SNA-NJE, my single instance shop converted to JES2 so we saved by
>> both not having to pay for BDT but also JES2 was cheaper.
>
>Good observation!
>
>I didn't specify whether I was referring to the BDT SNA/NJE function or 
>the BDT File-to-File function.

I think that IBM dead ended and stopped support of the File-to-file
and all other non-JES3 related functions at least 18 years ago.

Clark Morris
>
>I was thinking of the latter...

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

Re: EBCDIC and other systems

[Cameron Conacher]

I have used Japanese (930) and traditional Chinese (937) with the appropriate 
EBCDIC Host Code Page.
So yes DBCS is supported on a green screen

Sent from my iPhone

> On Aug 20, 2020, at 1:43 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Thu, 20 Aug 2020 09:35:40 -0700, Charles Mills wrote:
> 
>> I wonder if it might make sense to go UTF-32 even to disk, but compress the 
>> data.
>> 
>> I wonder how well standard compression schemes work with UTF-32? Are they 
>> too octet-oriented to work optimally?
>> 
> A non-scientific sample:
> 1995 $ ls -l ~ | wc
> 24 2131403
> 1996 $ ls -l ~ |gzip | wc
>  1   9 441
> 1997 $ ls -l ~ | iconv -f UTF-8 -t UTF-32 | wc
> 24 2135616
> 1998 $ ls -l ~ | iconv -f UTF-8 -t UTF-32 | gzip | wc
>  0   9 679
> 
>> I wonder if one might write an LZW implementation that assumed 32-bit 
>> characters.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Anyone Using MVS Bulk Data Transfer (File-to-File)?

[Ed Jaffe]

On 8/20/2020 1:14 PM, Clark Morris wrote:


Any shop using SNA-NJE on JES3 needs it.  Since JES2 didn't require it
for SNA-NJE, my single instance shop converted to JES2 so we saved by
both not having to pay for BDT but also JES2 was cheaper.


Good observation!

I didn't specify whether I was referring to the BDT SNA/NJE function or 
the BDT File-to-File function.


I was thinking of the latter...


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



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Anyone Using MVS Bulk Data Transfer?

[Clark Morris]

[Default] On 20 Aug 2020 09:02:35 -0700, in bit.listserv.ibm-main
edja...@phoenixsoftware.com (Ed Jaffe) wrote:

>Came across someone using this product and wondered how popular it was.
>
Any shop using SNA-NJE on JES3 needs it.  Since JES2 didn't require it
for SNA-NJE, my single instance shop converted to JES2 so we saved by
both not having to pay for BDT but also JES2 was cheaper.  I modified
the EXIT from American Natural Resources and some other JES and MVS
exits to keep the system looking somewhat like JES3 to the
programmers.  The concurrent installation of CA-DISPATCH - a report
manager also helped.  The conversion to JES2 forced getting all
production jobs converted to use CA-DISPATCH before the JES2 cutover
so the projects fed each other.

Clark Morris

>Has it been replaced by more-recent z/OS functionality? Or does it 
>remain the only way to do certain things?
>
>Thanks,

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

Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Matthew Stitt]

Check the z/OS Initialization and Tuning Reference.  Table 55 lists the 
supplied entries for the SCHEDxx PPT.  This is what I used to clean up my PPT 
entries.

Matthew

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

Re: Can System REXX run Sub=MSTR ??

[ITschak Mugzach]

Systemrexx is started automatically during IPL. What are you trying to get?

ITschak
בתאריך יום ה׳, 20 באוג׳ 2020, 22:33, מאת Lionel B Dyck ‏:

> And if so where would that be changed as I can't find where it is started
> now?
>
>
>
> Thanks in advance.
>
>
>
>
>
> Lionel B. Dyck <
> Website:   https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
>
>
>
> --
> 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: Can System REXX run Sub=MSTR ??

[Itschak Mugzach]

Systemrexx is started automatically during IPL. What are the advantage of
running systemrexx under the mstr subsys?

ITs hak
בתאריך יום ה׳, 20 באוג׳ 2020, 22:33, מאת Lionel B Dyck ‏:

> And if so where would that be changed as I can't find where it is started
> now?
>
>
>
> Thanks in advance.
>
>
>
>
>
> Lionel B. Dyck <
> Website:   https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
>
>
>
> --
> 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

Can System REXX run Sub=MSTR ??

[Lionel B Dyck]

And if so where would that be changed as I can't find where it is started
now?

 

Thanks in advance.

 

 

Lionel B. Dyck <
Website:   https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

 


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

Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Carmen Vitullo]

maybe somewhat helpful, I checked the CA-AUDIT report I received and checked 
out SCHED00 member 
this is what I found

  DATASET   SMFPREF
 PROGRAM  WHEREINTEG  SECURITY  NON-   TIMING CPU  STOR
  NAMESOURCE  FOUND   BYPASS  KEY  BYPASS  CANCEL SWAP BYPASS AFFN FLAG
   -    --  --- ---  --  --  

 DXRRLM00 IBMIEFSDPPT  NO 7  NO  NO   NO YES  ALL
* DXRRLM00 IBMSCHED00   NO 7  NO  NO   NO YES  ALL   001

hopefully the text does not get messed up 
what I found is for IRLM it's already defined in IEFSDPPT and we have it 
defined in SCHED00, so maybe a migration step was skipped or not documented to 
remove the entry 
Carmen

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

Re: EBCDIC and other systems

[Paul Gilmartin]

On Thu, 20 Aug 2020 09:35:40 -0700, Charles Mills wrote:

>I wonder if it might make sense to go UTF-32 even to disk, but compress the 
>data.
>
>I wonder how well standard compression schemes work with UTF-32? Are they too 
>octet-oriented to work optimally?
> 
A non-scientific sample:
1995 $ ls -l ~ | wc
 24 2131403
1996 $ ls -l ~ |gzip | wc
  1   9 441
1997 $ ls -l ~ | iconv -f UTF-8 -t UTF-32 | wc
 24 2135616
1998 $ ls -l ~ | iconv -f UTF-8 -t UTF-32 | gzip | wc
  0   9 679

>I wonder if one might write an LZW implementation that assumed 32-bit 
>characters.

-- gil

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

HMC - Terminal session capability for SLU

[Jake Anderson]

Cross posted

Hello

We are trying to set up non SNA terminal definition.

Is there a way to set up Terminal session capability for SLU ?

Regards
Jake

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

Re: EBCDIC and other systems

[Paul Gilmartin]

On Thu, 20 Aug 2020 16:08:47 +0100, Rupert Reynolds wrote:

>Charles: Good points well made. Yes, I agree that UTF-16 offers no
>advantage to me. UTF-32 has to be considered for performance in string
>handling functions. I may end up defaulting to UTF-8 on disc, and
>converting to the others when needed.
>
Does "when needed" cover importing/exporting data to foreign systems?

I have mixed feelings about z/OS's facility of tagging files with CCSID.
From a POSIX purist's viewpoint it's a repugnant extension.  OTOH,
ISPF View/Edit's support of tagging is excellent.  I can Edit a UTF-8
file and characters display clearly, only limited by the CCSID of the
terminal.  But won't honor CCSID tagging of macros.  (Does ISPF
support any DBCS terminals?  Which?)

>The system's source and compiler (crude but working) are all written in
>7-bit ASCII to keep things simple, but data can be any value--I'm not a big
>fan of stringz :-)
>
7-bit ASCII doesn't well support UTF-8.  Rely on UTF-8's being a superset
of USASCII and consider all non-ASCII characters ordinary, not metacharacters.

-- gil

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

Re: EBCDIC and other systems

[Charles Mills]

I wonder if it might make sense to go UTF-32 even to disk, but compress the 
data.

I wonder how well standard compression schemes work with UTF-32? Are they too 
octet-oriented to work optimally?

I wonder if one might write an LZW implementation that assumed 32-bit 
characters.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rupert Reynolds
Sent: Thursday, August 20, 2020 8:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC and other systems

Charles: Good points well made. Yes, I agree that UTF-16 offers no
advantage to me. UTF-32 has to be considered for performance in string
handling functions. I may end up defaulting to UTF-8 on disc, and
converting to the others when needed.

The system's source and compiler (crude but working) are all written in
7-bit ASCII to keep things simple, but data can be any value--I'm not a big
fan of stringz :-)

To be frank, I doubt it will have more than 1 user, but I won't be happy
until I can write and print my CV on it, so I might as well make some
sensible decisions now :-)

Thank you.

Rupert

On Thu., Aug. 20, 2020, 15:17 Charles Mills,  wrote:

> Not exactly the question you asked, but IMHO if one were writing a
> "system" (OS, DBMS, application family) today one would be foolish to
> restrict one's customers to 95 or so printable characters. You would be (1)
> writing off all of Asia and (2) condemning much of Europe and northern
> Africa to either second class status, or the constant code page shuffle
> ("what character is x'80'? Well, it depends where you are.")
>
> Other than the above you have three choices:
>
> - UTF-8, which will represent every character in the world, is almost as
> compact as ASCII, and can be treated as ASCII for quick-and-dirty purposes
> like debugging displays. What you give up is the comforting knowledge that
> characters are always, always, always one to one with bytes.
>
> - UTF-32. Like UTF-8, but you gain a fixed relationship between characters
> and bytes (1:4) at a cost in storage. You might counter that storage is
> cheap these days.
>
> - I am not a Windows-basher, but I think Windows' choice of UTF-16 is the
> worst of both worlds. It consumes twice the storage of ASCII, with the
> tradeoff that you can almost, almost, almost count on a fixed relationship
> between characters and bytes (1:2). The problem is that you cannot quite
> count on it -- some characters are 32 bits -- and if you have supported
> code that is running out in the field you know that code that works 99.9%
> of the time is much more problematic than code that works 95% of the time
> (as would a routine that assumed UTF-8 was 1:1 with bytes).
>
> Most Web pages, the Go Language, and Db2 (I am told) all use UTF-8
> internally.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rupert Reynolds
> Sent: Thursday, August 20, 2020 5:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EBCDIC and other systems
>
> I'm writing a new OS for PC hardware (an exercise started during
> lockdown/furlough) and I wondered about files from other systems. Is there
> much in DBCS on mainframe systems these days, or is it still mainly the
> same old 8-bit EBCDIC, please?
>
> I still have to decide whether to support UTF-8 and/or UTF-32, of course
> :-)
>
> --
> 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: DFSORT confusion.

[Sri h Kolusu]

> That was it. I ran a SUPERCE to find the difference. I then did a FIND in
> each file for the first difference. The first file had an M in the
> position. The second one did not.

John,

As Dave Betten kindly pointed it is the order of processing of statements
that produced different results.  I would suggest that the programmer have
this chart handy to understand the order of record processing

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icea100/ice2ca_DFSORT_processing_.htm#idg7073__stmtseq


Thanks,
Kolusu
DFSORT Development
IBM Corporation

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

Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Michael Babcock]

And I thought there was a D PPT command now too.

On Thu, Aug 20, 2020 at 8:11 AM Peter Relson  wrote:

> It doesn't seem like the posts were answering Lizette's thought/question.
>
>
>
> 
>
> I have been researching whether we need to review all of our SCHEDxx for
>
> PPT
>
> and remove anything that is currently shipped by IBM in Linklib for
>
> IEFSDPPT
>
> 
>
>
>
> This relates to whether you want things in your SCHEDxx that are shipped
>
> in IEFSDPPT?
>
> If you're not changing the values, why would you want the duplication?
>
> That's just extra maintenance for you.
>
> Does IRLM instruct you to use SCHEDxx for DFSMVRC0 or DXRRLM00? If so, I
>
> wonder why. If they don't, why did you?
>
>
>
> Peter Relson
>
> z/OS Core Technology Design
>
>
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: Anyone Using MVS Bulk Data Transfer?

[Steve Beaver]

Most folks use CONNECT: Direct.  NDM but it is expensive 

Sent from my iPhone

I promise you I can’t type or
Spell on any smartphone 

> On Aug 20, 2020, at 11:02, Ed Jaffe  wrote:
> 
> Came across someone using this product and wondered how popular it was.
> 
> Has it been replaced by more-recent z/OS functionality? Or does it remain the 
> only way to do certain things?
> 
> Thanks,
> 
> -- 
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
> 
> 
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
> 
> --
> 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

Anyone Using MVS Bulk Data Transfer?

[Ed Jaffe]

Came across someone using this product and wondered how popular it was.

Has it been replaced by more-recent z/OS functionality? Or does it 
remain the only way to do certain things?


Thanks,

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



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Carmen Vitullo]

My main question is which should be used?

The sysprogs over time do not always read manuals or review parmlib for 
changes.  I know this has been out there for a really long time.

I am trying to understand which is needed today.

If we should go with the LINKLIB module, what do I do to SCHEDxx - remove it 
from PARMLIB?  Not worry about it as the LINKLIB over rules the Parmlib?

The IRLM team is recommending we let LINKLIB handle this.  I can remove IRLM 
code from SCHEDxx.  But since there are other entries in SCHEDxx - I would 
prefer to do one pass rather than have to come back to this again.

So - questions
1) Who wins - LINKLIB or PARMLIB
2) Should SCHEDxx only contain OEM entries and all previous IBM Entries be 
removed
3) What is best practice

Thank you 

Lizette

I didn't believe our auditor so I check, the Init and Tuning Reference page 718 
provides a list of PPT entries that are supplied by default 
stated above that -
PPT
Allows the installation to specify a list of programs that require special 
attributes or to change the
attributes of the IBM-supplied default entries in the PPT (see Table 55 on page 
718). The system
scans this PPT to determine which, if any, special attributes apply to the 
program it is initiating.
Note:
1. Usually, you should not add or change programs in the program properties 
table (PPT) unless the
instructions for installing a program direct you to do so. If you do add a 
program to the PPT, or
change an existing entry's properties, ensure that the program can function 
with the properties you
have assigned to it. For example, a program designed to run in program protect 
key 8 might not be
able to run in key 10 because of hardcoded key speci®ctions in the program. If 
you were to
specify KEY(10) in this case, the program will not function correctly.
2. If the processor that your system runs on does not support program protect 
key 9, do not assign
key 9 to any programs. For speci®c processor models, see z/OS Planning for 
Installation.

I hope this helps some 
Carmen 

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

Re: EBCDIC and other systems

[Rupert Reynolds]

Charles: Good points well made. Yes, I agree that UTF-16 offers no
advantage to me. UTF-32 has to be considered for performance in string
handling functions. I may end up defaulting to UTF-8 on disc, and
converting to the others when needed.

The system's source and compiler (crude but working) are all written in
7-bit ASCII to keep things simple, but data can be any value--I'm not a big
fan of stringz :-)

To be frank, I doubt it will have more than 1 user, but I won't be happy
until I can write and print my CV on it, so I might as well make some
sensible decisions now :-)

Thank you.

Rupert

On Thu., Aug. 20, 2020, 15:17 Charles Mills,  wrote:

> Not exactly the question you asked, but IMHO if one were writing a
> "system" (OS, DBMS, application family) today one would be foolish to
> restrict one's customers to 95 or so printable characters. You would be (1)
> writing off all of Asia and (2) condemning much of Europe and northern
> Africa to either second class status, or the constant code page shuffle
> ("what character is x'80'? Well, it depends where you are.")
>
> Other than the above you have three choices:
>
> - UTF-8, which will represent every character in the world, is almost as
> compact as ASCII, and can be treated as ASCII for quick-and-dirty purposes
> like debugging displays. What you give up is the comforting knowledge that
> characters are always, always, always one to one with bytes.
>
> - UTF-32. Like UTF-8, but you gain a fixed relationship between characters
> and bytes (1:4) at a cost in storage. You might counter that storage is
> cheap these days.
>
> - I am not a Windows-basher, but I think Windows' choice of UTF-16 is the
> worst of both worlds. It consumes twice the storage of ASCII, with the
> tradeoff that you can almost, almost, almost count on a fixed relationship
> between characters and bytes (1:2). The problem is that you cannot quite
> count on it -- some characters are 32 bits -- and if you have supported
> code that is running out in the field you know that code that works 99.9%
> of the time is much more problematic than code that works 95% of the time
> (as would a routine that assumed UTF-8 was 1:1 with bytes).
>
> Most Web pages, the Go Language, and Db2 (I am told) all use UTF-8
> internally.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rupert Reynolds
> Sent: Thursday, August 20, 2020 5:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EBCDIC and other systems
>
> I'm writing a new OS for PC hardware (an exercise started during
> lockdown/furlough) and I wondered about files from other systems. Is there
> much in DBCS on mainframe systems these days, or is it still mainly the
> same old 8-bit EBCDIC, please?
>
> I still have to decide whether to support UTF-8 and/or UTF-32, of course
> :-)
>
> --
> 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 confusion.

[Bob Bridges]

I am repeatedly amazed at supposedly professional computer people who don't 
know how to report problems.  When an end user calls me and says "it didn't 
work", I get it; I have to drag the necessary information out of him with 
pointed and sometimes repeated questions ("What ~did~ it do?"  "Nothing."  " 
'Nothing'?  You mean the computer stopped?  The screen was blank?  The power 
went off?  Or was there, by chance, an error message?")  But when the plaintiff 
is a programmer, what's up with that?

Sigh.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* In the twinkling of an eye, in a time too small to be measured, and in any 
place, all that seems to divide us from God can flee away, vanish leaving us 
naked before Him, like the first man, like the only man, as if nothing but He 
and I existed.  And since that contact cannot be avoided for long, and since it 
means either bliss or horror, the business of life is to learn to like it.  -C 
S Lewis, _Dogma and the Universe_ */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, August 20, 2020 08:33

The first file had an M in the position. The second one did not. I think 
the programmer is trying to recover deleted records, and so the second, OUTFIL, 
seems, to me, to be what he wants. But that's up to him. The programmers never 
seem to tell us what they want, just "this isn't doing what I expect".

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

Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Carmen Vitullo]

I'm afraid to say I am in the same boat, old entries never removed for the same 
reason, If there are duplicate entries I'm not sure who wins, I suspect SCHEDxx 
because it is loaded after? 
I suspect only OEM product entries should be in SCHEDxx but I probably have 
entries that need to be reviewed and removed also like JES CICS, IMS
I am also curious what others have done, used as a best practice ?

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

Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Lizette Koehler]

My main question is which should be used?

The sysprogs over time do not always read manuals or review parmlib for 
changes.  I know this has been out there for a really long time.

I am trying to understand which is needed today.

If we should go with the LINKLIB module, what do I do to SCHEDxx - remove it 
from PARMLIB?  Not worry about it as the LINKLIB over rules the Parmlib?

The IRLM team is recommending we let LINKLIB handle this.  I can remove IRLM 
code from SCHEDxx.  But since there are other entries in SCHEDxx - I would 
prefer to do one pass rather than have to come back to this again.

So - questions
1) Who wins - LINKLIB or PARMLIB
2) Should SCHEDxx only contain OEM entries and all previous IBM Entries be 
removed
3) What is best practice

Thank you 

Lizette



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Thursday, August 20, 2020 7:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

It doesn't seem like the posts were answering Lizette's thought/question.


I have been researching whether we need to review all of our SCHEDxx for PPT 
and remove anything that is currently shipped by IBM in Linklib for IEFSDPPT 


This relates to whether you want things in your SCHEDxx that are shipped in 
IEFSDPPT?
If you're not changing the values, why would you want the duplication? 
That's just extra maintenance for you.
Does IRLM instruct you to use SCHEDxx for DFSMVRC0 or DXRRLM00? If so, I wonder 
why. If they don't, why did you?

Peter Relson
z/OS Core Technology Design


We went through this with our DISA STIG's 

Review the IEFSDPPT module and all programs that IBM has, by default, placed in 
the PPT to validate their applicability to the execution system. Refer to the 
IBM z/OS MVS Initialization and Tuning Reference documentation for the version 
and release of z/OS installed at the individual site for the actual contents of 
the default IEFSDPPT.

the auditors could not find any reference to the defaults supplied in the init 
and tuning guide,  we found CA-AUDITOR provides a list of what modules are 
currently in the PPT and where they were defined'
the STIG instructed us to use
TSO ISRDDN LOAD IEFSDPPT to list the currently loaded PPT entries, but will not 
show where they came from. 

I'm with Peter, safe choice ! Does IRLM instruct you to use SCHEDxx for 
DFSMVRC0 or DXRRLM00? If so, I wonder why. If they don't, why did you?

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

Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Carmen Vitullo]

It doesn't seem like the posts were answering Lizette's thought/question.


I have been researching whether we need to review all of our SCHEDxx for PPT 
and remove anything that is currently shipped by IBM in Linklib for IEFSDPPT 


This relates to whether you want things in your SCHEDxx that are shipped in 
IEFSDPPT?
If you're not changing the values, why would you want the duplication? 
That's just extra maintenance for you.
Does IRLM instruct you to use SCHEDxx for DFSMVRC0 or DXRRLM00? If so, I wonder 
why. If they don't, why did you?

Peter Relson
z/OS Core Technology Design


We went through this with our DISA STIG's 

Review the IEFSDPPT module and all programs that IBM has, by default, placed in 
the PPT to validate their
applicability to the execution system. Refer to the IBM z/OS MVS Initialization 
and Tuning Reference
documentation for the version and release of z/OS installed at the individual 
site for the actual contents of the
default IEFSDPPT.

the auditors could not find any reference to the defaults supplied in the init 
and tuning guide,
 we found CA-AUDITOR provides a list of what modules are currently in the PPT 
and where they were defined'
the STIG instructed us to use
TSO ISRDDN LOAD IEFSDPPT to list the currently loaded PPT entries, but will not 
show where they came from. 

I'm with Peter, safe choice ! Does IRLM instruct you to use SCHEDxx for 
DFSMVRC0 or DXRRLM00? If so, I wonder why. If they don't, why did you?

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

Re: EBCDIC and other systems

[Rupert Reynolds]

Thank you.

Yes, codepages are another layer to handle, but I'm mainly making sure I
don't make too many design mistakes early on that make things difficult
later :-)

Rupert

On Thu., Aug. 20, 2020, 14:00 Cameron Conacher,  wrote:

> There are many EBCDIC codepages.
> DBCS is used by japan, China, Korea and Vietnam.
> Our Japanese customers use EBCDIC codepage 930. Our Taiwanese customers
> use EBCDIC codepage 937.
>
>
> Sent from my iPhone
>
> > On Aug 20, 2020, at 8:54 AM, Rupert Reynolds 
> wrote:
> >
> > I'm writing a new OS for PC hardware (an exercise started during
> > lockdown/furlough) and I wondered about files from other systems. Is
> there
> > much in DBCS on mainframe systems these days, or is it still mainly the
> > same old 8-bit EBCDIC, please?
> >
> > I still have to decide whether to support UTF-8 and/or UTF-32, of course
> :-)
> >
> > Roo
> >
> > --
> > 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: EBCDIC and other systems

[Charles Mills]

Not exactly the question you asked, but IMHO if one were writing a "system" 
(OS, DBMS, application family) today one would be foolish to restrict one's 
customers to 95 or so printable characters. You would be (1) writing off all of 
Asia and (2) condemning much of Europe and northern Africa to either second 
class status, or the constant code page shuffle ("what character is x'80'? 
Well, it depends where you are.")

Other than the above you have three choices:

- UTF-8, which will represent every character in the world, is almost as 
compact as ASCII, and can be treated as ASCII for quick-and-dirty purposes like 
debugging displays. What you give up is the comforting knowledge that 
characters are always, always, always one to one with bytes.

- UTF-32. Like UTF-8, but you gain a fixed relationship between characters and 
bytes (1:4) at a cost in storage. You might counter that storage is cheap these 
days.

- I am not a Windows-basher, but I think Windows' choice of UTF-16 is the worst 
of both worlds. It consumes twice the storage of ASCII, with the tradeoff that 
you can almost, almost, almost count on a fixed relationship between characters 
and bytes (1:2). The problem is that you cannot quite count on it -- some 
characters are 32 bits -- and if you have supported code that is running out in 
the field you know that code that works 99.9% of the time is much more 
problematic than code that works 95% of the time (as would a routine that 
assumed UTF-8 was 1:1 with bytes).

Most Web pages, the Go Language, and Db2 (I am told) all use UTF-8 internally. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rupert Reynolds
Sent: Thursday, August 20, 2020 5:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EBCDIC and other systems

I'm writing a new OS for PC hardware (an exercise started during
lockdown/furlough) and I wondered about files from other systems. Is there
much in DBCS on mainframe systems these days, or is it still mainly the
same old 8-bit EBCDIC, please?

I still have to decide whether to support UTF-8 and/or UTF-32, of course :-)

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

MQ Archive Logs (MQ Noob question)

[Michael Knigge]

Hi,

we’re running MQ on a zPDF (preconfigured ADCD z/OS distribution) and we need 
MQ only from time to time for testing purposes… So backup, desaster recovery 
and so on is not required at our site.

Now…. Since several days, I see the following messages in the Log and the queue 
manager has stopped working:


CSQJ139I %CSQ8 LOG OFFLOAD TASK ENDED
CSQJ111A %CSQ8 OUT OF SPACE IN ACTIVE LOG DATA SETS
CSQJ073E %CSQ8 LOG ARCHIVE UNIT ALLOCATION FAILED, 829
REASON CODE=0008. ALLOCATION OR OFFLOAD OF ARCHIVE LOG DATA SET MAY FAIL
IKJ56241I DATA SET CSQARC1.B043 NOT ALLOCATED+
IKJ56241I SPECIFIED UNIT IS UNDEFINED
CSQJ008E %CSQ8  6 OF  8 ACTIVE LOGS ARE FULL, CSQ8 NEEDS ARCHIVE SCRATCH
*06 CSQJ021D %CSQ8 REPLY Y WHEN DEVICE READY OR N TO CANCEL


Now…. I’m a complete MQ noob but I’ve read the manuals and what I’ve got so far 
is, that MQ tries to offload data from the active log tot he archive log – but 
it fails… I also found some information in the log regarding the configuration 
of MQ:

CSQY110I %CSQ8 LOG parameters ...
CSQY111I %CSQ8 INBUFF=60, OUTBUFF=4000, MAXRTU=2, MAXARCH=500
CSQY112I %CSQ8 TWOACTV=YES, TWOARCH=YES, TWOBSDS=YES
CSQY113I %CSQ8 OFFLOAD=YES, WRTHRSH=20, DEALLCT=0, COMPLOG=NONE
CSQY120I %CSQ8 ARCHIVE parameters ...
CSQY121I %CSQ8 UNIT=TAPE, UNIT2=, ALCUNIT=BLK, PRIQTY=25715, SECQTY=540, 
BLKSIZE=28672
CSQY122I %CSQ8 ARCPFX1=CSQARC1, ARCPFX2=CSQARC2, TSTAMP=NO
CSQY123I %CSQ8 ARCRETN=, ARCWTOR=YES, ARCWRTC=( 1 ,3 ,4)
CSQY124I %CSQ8 CATALOG=NO, COMPACT=NO, PROTECT=NO, QUIESCE=5


So if I get all this stuff right, then MQ is configured to offload to tape 
(which I don’t have on my zPDT system)….

Well… Is there any „good way“ to tell MQ „don’t care, don’t offload“ (as said, 
we don’t care for backups etc in our use case)? Maybe something I can issue at 
runtime?

If not, can anyone tell me how to configure MQ ? I’ve found 
CSQ800.SCSQPROC(CSQ4ZPRM) on my system – I guess I have to modify this and 
assemble the load module? But the the next question:


//SYSLIN   DD *
   INCLUDE SYSP
   INCLUDE ARVP
   INCLUDE LOGP
   INCLUDE OLDLOAD(CSQZPARM)
 ENTRY CSQZMSTR
 NAME ++NAME++(R)   Your system parameter module name
/*
//

Well…. What is the name of my „system parameter module name“???


Thank you very very much…

Michael







Mit freundlichen Grüßen

Michael Knigge
Software Engineer

SET GmbH
Rühmkorffstraße 5
30163 Hannover

Telefon: +49 511 330 998 23
Fax: +49 511 330 998 65
michael.kni...@set.de
https://www.set.de

Handelsregister: Amtsgericht Hannover HRB 52778
​Geschäftsführer: Dr.-Ing. Tobias Baum, Arthur Brack, Hendrik Leder


Mit freundlichen Grüßen

Michael Knigge



SET GmbH
Rühmkorffstraße 5
30163 Hannover

Telefon: +49 511 330 998 23
Fax: +49 511 330 998 65
michael.kni...@set.de
www.set.de

Handelsregister: Amtsgericht Hannover HRB 52778
​Geschäftsführer: Tobias Baum, Arthur Brack, Hendrik Leder 

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

Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib

[Peter Relson]

It doesn't seem like the posts were answering Lizette's thought/question.


I have been researching whether we need to review all of our SCHEDxx for 
PPT
and remove anything that is currently shipped by IBM in Linklib for 
IEFSDPPT


This relates to whether you want things in your SCHEDxx that are shipped 
in IEFSDPPT?
If you're not changing the values, why would you want the duplication? 
That's just extra maintenance for you.
Does IRLM instruct you to use SCHEDxx for DFSMVRC0 or DXRRLM00? If so, I 
wonder why. If they don't, why did you?

Peter Relson
z/OS Core Technology Design


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

Re: EBCDIC and other systems

[Cameron Conacher]

There are many EBCDIC codepages.
DBCS is used by japan, China, Korea and Vietnam.
Our Japanese customers use EBCDIC codepage 930. Our Taiwanese customers use 
EBCDIC codepage 937.


Sent from my iPhone

> On Aug 20, 2020, at 8:54 AM, Rupert Reynolds  wrote:
> 
> I'm writing a new OS for PC hardware (an exercise started during
> lockdown/furlough) and I wondered about files from other systems. Is there
> much in DBCS on mainframe systems these days, or is it still mainly the
> same old 8-bit EBCDIC, please?
> 
> I still have to decide whether to support UTF-8 and/or UTF-32, of course :-)
> 
> Roo
> 
> --
> 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: Strange S0C4 on z15

[Peter Relson]

On a z13 we could access data in the PSA in the 2048 to 4095 range without 
going into key 0.  The specific field is PSASVT. 


If you can prove that, then please report it immediately as a defect. But 
I'd think you can't.
Is it possible that you used to access the SVT via CVTSVT?

Peter Relson
z/OS Core Technology Design


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

EBCDIC and other systems

[Rupert Reynolds]

I'm writing a new OS for PC hardware (an exercise started during
lockdown/furlough) and I wondered about files from other systems. Is there
much in DBCS on mainframe systems these days, or is it still mainly the
same old 8-bit EBCDIC, please?

I still have to decide whether to support UTF-8 and/or UTF-32, of course :-)

Roo

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

Re: DFSORT confusion.

[John McKown]

That was it. I ran a SUPERCE to find the difference. I then did a FIND in
each file for the first difference. The first file had an M in the
position. The second one did not. I think the programmer is trying to
recover deleted records, and so the second, OUTFIL, seems, to me, to be
what he wants. But that's up to him. The programmers never seem to tell us
what they want, just "this isn't doing what I expect".

On Thu, Aug 20, 2020 at 7:23 AM David Betten  wrote:

> It has to do with the order of the operations.  OMIT is done on input,
> prior to the summing.  OUTFIL happens on output, after the summing.
>
> Consider four records
> key   Include field
> KEY1  M
> KEY1 P
> KEY1 M
> KEY1 Q
>
> With SUM and OMIT
> OMIT will remove the M records 1 and 3 on input leaving the KEY1 P and KEY1
> Q records
> SUM then removes the Q record
> Left with 1 output record KEY1 P
>
> SUM and OUTFIL
> All the records are passed to the sort
> SUM removes records 2,3,4 leaving the first KEY1 M record
> OUTFIL then removes the KEY1 M record
> No records go to output
>
>
> Have a nice day,
> Dave Betten
> z/OS Performance Specialist
> Cloud and Systems Performance
> IBM Corporation
> email:  bet...@us.ibm.com
>
> IBM Mainframe Discussion List  wrote on
> 08/20/2020 07:26:45 AM:
>
> > From: John McKown 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 08/20/2020 07:27 AM
> > Subject: [EXTERNAL] DFSORT confusion.
> > Sent by: IBM Mainframe Discussion List 
> >
> > This is on z/OS 1.12 (sorry). A programmer has run two DFSORT jobs with
> > slightly different control statements which both of us think should
> result
> > in the same output. But it does not. One uses the OMIT statement. The
> other
> > uses an OUTFIL with a COND. Both use SUM FIELDS=NONE and EQUALS=YES to
> > remove all duplicate keys, keeping the first record. But the output is
> > different. The OMIT run has more records. A quick look seems to indicate
> > that OMIT is what he really wants. Here are the DFSOFT messages. I just
> > can't see why the OMIT has more output. Most likely due to my own lack of
> > understanding.
> >
> > === OMIT ===
> >
> > 1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> >
> >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> > E5-K70685 E6-K58148 C4-K58148 E7-K70685
> >  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
> >
> >  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> > EXAMPLES AND MORE
> >  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:41
> ON
> > WED AUG 19, 2020 -
> > 0SORT FIELDS=(13,16,CH,A),EQUALS
> > 00190001
> >  SUM FIELDS=NONE
> > 0021
> >  OMIT COND=(191,1,CH,EQ,C'M')   DROP M* POLICIES
> > 00210001
> >  ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> >
> >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> > E5-K70685 E6-K58148 C4-K58148 E7-K70685
> >  ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
> > SELECTED
> >  ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
> > 27998, TYPE = VB
> >  ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)
> >
> >  ICE156I 0 MAIN STORAGE ABOVE 16MB = (38819828,38819828)
> >
> >  ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
> > ,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
> >  ICE128I 0 OPTIONS:
> > SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS=Y,LIST=Y,ERET=RC16
> > ,MSGDDN=SYSOUT
> >  ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
> > ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA   ,031),ABCODE=MSG
> >  ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109
> > ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
> >  ICE131I 0 OPTIONS:
> > TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64
> >
> >  ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
> >  ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
> >  ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
> > ,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=0
> >  ICE235I 0 OPTIONS: NULLOUT=RC0
> >
> >  ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y
> >
> >  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT
> >
> >  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN
> >
> >  ICE750I 0 DC 10419394794 TC 0 CS DSVUU KSZ 20 VSZ 20
> >
> >  ICE752I 0 FSZ=10419394794 BC  IGN=0 E  AVG=6143 0  WSP=13535205 C
> >  DYN=244621 56664
> >  ICE751I 1 D8-K58148 D4-K59452 EA-K59517 F1-K58148 E8-K70685
> >
> >  ICE090I 0 OUTPUT LRECL = 12285, BLKSIZE = 27998, TYPE = VB
> >
> >  ICE055I 0 INSERT 0, DELETE 1068329
> >
> >  ICE054I 0 RECORDS - IN: 6258994, OUT: 5190665
> >
> >  ICE134I 0 NUMBER OF BYTES SORTED: 7993209593
> >
> >  ICE253I 0 RECORDS SORTED - PROCESSED: 5215434, EXPECTED: 1696417
> >
> >  ICE098I 0 AVERAGE RECORD LENGTH - PROCESSED: 1532, EXPECTED: 6142
> >
> >  ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 245055 , TRACKS USED:
> > 145365
> >  ICE199I 0 MEMORY OBJECT USED AS MAIN STORAGE = 0M BYTES
> >
> >  ICE299I 0 ME

Re: DFSORT confusion.

[David Betten]

It has to do with the order of the operations.  OMIT is done on input,
prior to the summing.  OUTFIL happens on output, after the summing.

Consider four records
key   Include field
KEY1  M
KEY1 P
KEY1 M
KEY1 Q

With SUM and OMIT
OMIT will remove the M records 1 and 3 on input leaving the KEY1 P and KEY1
Q records
SUM then removes the Q record
Left with 1 output record KEY1 P

SUM and OUTFIL
All the records are passed to the sort
SUM removes records 2,3,4 leaving the first KEY1 M record
OUTFIL then removes the KEY1 M record
No records go to output


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com

IBM Mainframe Discussion List  wrote on
08/20/2020 07:26:45 AM:

> From: John McKown 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/20/2020 07:27 AM
> Subject: [EXTERNAL] DFSORT confusion.
> Sent by: IBM Mainframe Discussion List 
>
> This is on z/OS 1.12 (sorry). A programmer has run two DFSORT jobs with
> slightly different control statements which both of us think should
result
> in the same output. But it does not. One uses the OMIT statement. The
other
> uses an OUTFIL with a COND. Both use SUM FIELDS=NONE and EQUALS=YES to
> remove all duplicate keys, keeping the first record. But the output is
> different. The OMIT run has more records. A quick look seems to indicate
> that OMIT is what he really wants. Here are the DFSOFT messages. I just
> can't see why the OMIT has more output. Most likely due to my own lack of
> understanding.
>
> === OMIT ===
>
> 1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
>
>  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> E5-K70685 E6-K58148 C4-K58148 E7-K70685
>  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
>
>  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> EXAMPLES AND MORE
>  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:41
ON
> WED AUG 19, 2020 -
> 0SORT FIELDS=(13,16,CH,A),EQUALS
> 00190001
>  SUM FIELDS=NONE
> 0021
>  OMIT COND=(191,1,CH,EQ,C'M')   DROP M* POLICIES
> 00210001
>  ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
>
>  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> E5-K70685 E6-K58148 C4-K58148 E7-K70685
>  ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
> SELECTED
>  ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
> 27998, TYPE = VB
>  ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)
>
>  ICE156I 0 MAIN STORAGE ABOVE 16MB = (38819828,38819828)
>
>  ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
> ,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
>  ICE128I 0 OPTIONS:
> SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS=Y,LIST=Y,ERET=RC16
> ,MSGDDN=SYSOUT
>  ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
> ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA   ,031),ABCODE=MSG
>  ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109
> ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
>  ICE131I 0 OPTIONS:
> TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64
>
>  ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
>  ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
>  ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
> ,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=0
>  ICE235I 0 OPTIONS: NULLOUT=RC0
>
>  ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y
>
>  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT
>
>  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN
>
>  ICE750I 0 DC 10419394794 TC 0 CS DSVUU KSZ 20 VSZ 20
>
>  ICE752I 0 FSZ=10419394794 BC  IGN=0 E  AVG=6143 0  WSP=13535205 C
>  DYN=244621 56664
>  ICE751I 1 D8-K58148 D4-K59452 EA-K59517 F1-K58148 E8-K70685
>
>  ICE090I 0 OUTPUT LRECL = 12285, BLKSIZE = 27998, TYPE = VB
>
>  ICE055I 0 INSERT 0, DELETE 1068329
>
>  ICE054I 0 RECORDS - IN: 6258994, OUT: 5190665
>
>  ICE134I 0 NUMBER OF BYTES SORTED: 7993209593
>
>  ICE253I 0 RECORDS SORTED - PROCESSED: 5215434, EXPECTED: 1696417
>
>  ICE098I 0 AVERAGE RECORD LENGTH - PROCESSED: 1532, EXPECTED: 6142
>
>  ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 245055 , TRACKS USED:
> 145365
>  ICE199I 0 MEMORY OBJECT USED AS MAIN STORAGE = 0M BYTES
>
>  ICE299I 0 MEMORY OBJECT USED AS WORK STORAGE = 0M BYTES
>
>  ICE180I 0 HIPERSPACE STORAGE USED = 0K BYTES
>
>  ICE188I 0 DATA SPACE STORAGE USED = 0K BYTES
>
>  ICE052I 0 END OF DFSORT
>
>
> === INCL ===
>
> 1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
>
>  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> E5-K70685 E6-K58148 C4-K58148 E7-K70685
>  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
>
>  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> EXAMPLES AND MORE
>  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:54
ON
> WED AUG 19, 2020 -
> 0SORT FIELDS=(13,16,CH,A),EQUALS
> 00190001
>  SUM FIELDS=NONE
> 00

Re: DFSORT confusion.

[Joe Monk]

Another thing you could do is flip the condition...

OUTFIL INCLUDE=(191,1,CH,EQ,C'M')
OMIT COND=(191,1,CH,NE,C'M')

This would include only the M records and then you could easily see (Since
its only about 200 records) what the conditions were doing ... and why they
were selected

Joe

On Thu, Aug 20, 2020 at 7:05 AM John McKown 
wrote:

> On Thu, Aug 20, 2020 at 7:03 AM Joe Monk  wrote:
>
> > What happens if you code the include like this?
> >
> > OUTFIL INCLUDE=(19,1,CH,EQ,C'ABCDEFGHIJKLNOPQRSTUVWXYZ0123456789')
> >
>
> Hum, I don't know why that would be any different, but I might try it if I
> get desperate enough.
>
>
>
> >
> > Joe
> >
> > On Thu, Aug 20, 2020 at 6:27 AM John McKown <
> john.archie.mck...@gmail.com>
> > wrote:
> >
> > > This is on z/OS 1.12 (sorry). A programmer has run two DFSORT jobs with
> > > slightly different control statements which both of us think should
> > result
> > > in the same output. But it does not. One uses the OMIT statement. The
> > other
> > > uses an OUTFIL with a COND. Both use SUM FIELDS=NONE and EQUALS=YES to
> > > remove all duplicate keys, keeping the first record. But the output is
> > > different. The OMIT run has more records. A quick look seems to
> indicate
> > > that OMIT is what he really wants. Here are the DFSOFT messages. I just
> > > can't see why the OMIT has more output. Most likely due to my own lack
> of
> > > understanding.
> > >
> > > === OMIT ===
> > >
> > > 1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> > >
> > >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> > > E5-K70685 E6-K58148 C4-K58148 E7-K70685
> > >  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
> > >
> > >  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> > > EXAMPLES AND MORE
> > >  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:41
> > ON
> > > WED AUG 19, 2020 -
> > > 0SORT FIELDS=(13,16,CH,A),EQUALS
> > > 00190001
> > >  SUM FIELDS=NONE
> > > 0021
> > >  OMIT COND=(191,1,CH,EQ,C'M')   DROP M* POLICIES
> > > 00210001
> > >  ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> > >
> > >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> > > E5-K70685 E6-K58148 C4-K58148 E7-K70685
> > >  ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
> > > SELECTED
> > >  ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
> > > 27998, TYPE = VB
> > >  ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)
> > >
> > >  ICE156I 0 MAIN STORAGE ABOVE 16MB = (38819828,38819828)
> > >
> > >  ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
> > > ,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
> > >  ICE128I 0 OPTIONS:
> > > SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS=Y,LIST=Y,ERET=RC16
> > > ,MSGDDN=SYSOUT
> > >  ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
> > > ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA   ,031),ABCODE=MSG
> > >  ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109
> > > ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
> > >  ICE131I 0 OPTIONS:
> > > TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64
> > >
> > >  ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
> > >  ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
> > >  ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
> > > ,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=0
> > >  ICE235I 0 OPTIONS: NULLOUT=RC0
> > >
> > >  ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y
> > >
> > >  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT
> > >
> > >  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN
> > >
> > >  ICE750I 0 DC 10419394794 TC 0 CS DSVUU KSZ 20 VSZ 20
> > >
> > >  ICE752I 0 FSZ=10419394794 BC  IGN=0 E  AVG=6143 0  WSP=13535205 C
> > >  DYN=244621 56664
> > >  ICE751I 1 D8-K58148 D4-K59452 EA-K59517 F1-K58148 E8-K70685
> > >
> > >  ICE090I 0 OUTPUT LRECL = 12285, BLKSIZE = 27998, TYPE = VB
> > >
> > >  ICE055I 0 INSERT 0, DELETE 1068329
> > >
> > >  ICE054I 0 RECORDS - IN: 6258994, OUT: 5190665
> > >
> > >  ICE134I 0 NUMBER OF BYTES SORTED: 7993209593
> > >
> > >  ICE253I 0 RECORDS SORTED - PROCESSED: 5215434, EXPECTED: 1696417
> > >
> > >  ICE098I 0 AVERAGE RECORD LENGTH - PROCESSED: 1532, EXPECTED: 6142
> > >
> > >  ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 245055 , TRACKS USED:
> > > 145365
> > >  ICE199I 0 MEMORY OBJECT USED AS MAIN STORAGE = 0M BYTES
> > >
> > >  ICE299I 0 MEMORY OBJECT USED AS WORK STORAGE = 0M BYTES
> > >
> > >  ICE180I 0 HIPERSPACE STORAGE USED = 0K BYTES
> > >
> > >  ICE188I 0 DATA SPACE STORAGE USED = 0K BYTES
> > >
> > >  ICE052I 0 END OF DFSORT
> > >
> > >
> > > === INCL ===
> > >
> > > 1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> > >
> > >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> > > E5-K70685 E6-K58148 C4-K58148 E7-K70685
> > >  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
> > >
> > >  ICE250I 0 VISIT http://www.ibm.c

Re: DFSORT confusion.

[John McKown]

On Thu, Aug 20, 2020 at 7:03 AM Joe Monk  wrote:

> What happens if you code the include like this?
>
> OUTFIL INCLUDE=(19,1,CH,EQ,C'ABCDEFGHIJKLNOPQRSTUVWXYZ0123456789')
>

Hum, I don't know why that would be any different, but I might try it if I
get desperate enough.



>
> Joe
>
> On Thu, Aug 20, 2020 at 6:27 AM John McKown 
> wrote:
>
> > This is on z/OS 1.12 (sorry). A programmer has run two DFSORT jobs with
> > slightly different control statements which both of us think should
> result
> > in the same output. But it does not. One uses the OMIT statement. The
> other
> > uses an OUTFIL with a COND. Both use SUM FIELDS=NONE and EQUALS=YES to
> > remove all duplicate keys, keeping the first record. But the output is
> > different. The OMIT run has more records. A quick look seems to indicate
> > that OMIT is what he really wants. Here are the DFSOFT messages. I just
> > can't see why the OMIT has more output. Most likely due to my own lack of
> > understanding.
> >
> > === OMIT ===
> >
> > 1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> >
> >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> > E5-K70685 E6-K58148 C4-K58148 E7-K70685
> >  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
> >
> >  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> > EXAMPLES AND MORE
> >  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:41
> ON
> > WED AUG 19, 2020 -
> > 0SORT FIELDS=(13,16,CH,A),EQUALS
> > 00190001
> >  SUM FIELDS=NONE
> > 0021
> >  OMIT COND=(191,1,CH,EQ,C'M')   DROP M* POLICIES
> > 00210001
> >  ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> >
> >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> > E5-K70685 E6-K58148 C4-K58148 E7-K70685
> >  ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
> > SELECTED
> >  ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
> > 27998, TYPE = VB
> >  ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)
> >
> >  ICE156I 0 MAIN STORAGE ABOVE 16MB = (38819828,38819828)
> >
> >  ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
> > ,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
> >  ICE128I 0 OPTIONS:
> > SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS=Y,LIST=Y,ERET=RC16
> > ,MSGDDN=SYSOUT
> >  ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
> > ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA   ,031),ABCODE=MSG
> >  ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109
> > ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
> >  ICE131I 0 OPTIONS:
> > TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64
> >
> >  ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
> >  ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
> >  ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
> > ,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=0
> >  ICE235I 0 OPTIONS: NULLOUT=RC0
> >
> >  ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y
> >
> >  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT
> >
> >  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN
> >
> >  ICE750I 0 DC 10419394794 TC 0 CS DSVUU KSZ 20 VSZ 20
> >
> >  ICE752I 0 FSZ=10419394794 BC  IGN=0 E  AVG=6143 0  WSP=13535205 C
> >  DYN=244621 56664
> >  ICE751I 1 D8-K58148 D4-K59452 EA-K59517 F1-K58148 E8-K70685
> >
> >  ICE090I 0 OUTPUT LRECL = 12285, BLKSIZE = 27998, TYPE = VB
> >
> >  ICE055I 0 INSERT 0, DELETE 1068329
> >
> >  ICE054I 0 RECORDS - IN: 6258994, OUT: 5190665
> >
> >  ICE134I 0 NUMBER OF BYTES SORTED: 7993209593
> >
> >  ICE253I 0 RECORDS SORTED - PROCESSED: 5215434, EXPECTED: 1696417
> >
> >  ICE098I 0 AVERAGE RECORD LENGTH - PROCESSED: 1532, EXPECTED: 6142
> >
> >  ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 245055 , TRACKS USED:
> > 145365
> >  ICE199I 0 MEMORY OBJECT USED AS MAIN STORAGE = 0M BYTES
> >
> >  ICE299I 0 MEMORY OBJECT USED AS WORK STORAGE = 0M BYTES
> >
> >  ICE180I 0 HIPERSPACE STORAGE USED = 0K BYTES
> >
> >  ICE188I 0 DATA SPACE STORAGE USED = 0K BYTES
> >
> >  ICE052I 0 END OF DFSORT
> >
> >
> > === INCL ===
> >
> > 1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> >
> >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> > E5-K70685 E6-K58148 C4-K58148 E7-K70685
> >  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
> >
> >  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> > EXAMPLES AND MORE
> >  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:54
> ON
> > WED AUG 19, 2020 -
> > 0SORT FIELDS=(13,16,CH,A),EQUALS
> > 00190001
> >  SUM FIELDS=NONE
> > 0021
> >  OUTFIL INCLUDE=(191,1,CH,NE,C'M')   DROP M* POLICIES
> >00210001
> >  ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> >
> >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> > E5-K70685 E6-K58148 C4-K58148 E7-K70685
> >  ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIR

Re: DFSORT confusion.

[John McKown]

On Thu, Aug 20, 2020 at 7:00 AM Billy Ashton  wrote:

> John, is it possible that some of the duplicate records have a different
> value in 187/191 - sometimes it has 'M', and sometimes something else?
>

Ah! A great idea. I had not thought of that.



>
> Can you compare the two different output files to see what is different
> (other than the 231 additional records)? Do you know which output set is
> correct?
>

OMIT is correct.



>
> Billy
> -- Original Message --
> From: "John McKown" 
> To: IBM-MAIN@listserv.ua.edu
> Sent: 8/20/2020 7:26:45 AM
> Subject: DFSORT confusion.
>
> >This is on z/OS 1.12 (sorry). A programmer has run two DFSORT jobs with
> >slightly different control statements which both of us think should result
> >in the same output. But it does not. One uses the OMIT statement. The
> other
> >uses an OUTFIL with a COND. Both use SUM FIELDS=NONE and EQUALS=YES to
> >remove all duplicate keys, keeping the first record. But the output is
> >different. The OMIT run has more records. A quick look seems to indicate
> >that OMIT is what he really wants. Here are the DFSOFT messages. I just
> >can't see why the OMIT has more output. Most likely due to my own lack of
> >understanding.
> >
> >=== OMIT ===
> >
> >1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> >
> >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> >E5-K70685 E6-K58148 C4-K58148 E7-K70685
> >  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
> >
> >  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> >EXAMPLES AND MORE
> >  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:41
> ON
> >WED AUG 19, 2020 -
> >0SORT FIELDS=(13,16,CH,A),EQUALS
> > 00190001
> >  SUM FIELDS=NONE
> > 0021
> >  OMIT COND=(191,1,CH,EQ,C'M')   DROP M* POLICIES
> > 00210001
> >  ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> >
> >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> >E5-K70685 E6-K58148 C4-K58148 E7-K70685
> >  ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
> >SELECTED
> >  ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
> >27998, TYPE = VB
> >  ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)
> >
> >  ICE156I 0 MAIN STORAGE ABOVE 16MB = (38819828,38819828)
> >
> >  ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
> >,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
> >  ICE128I 0 OPTIONS:
> >SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS=Y,LIST=Y,ERET=RC16
> >,MSGDDN=SYSOUT
> >  ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
> >,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA   ,031),ABCODE=MSG
> >  ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109
> >,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
> >  ICE131I 0 OPTIONS:
> >TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64
> >
> >  ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
> >  ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
> >  ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
> >,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=0
> >  ICE235I 0 OPTIONS: NULLOUT=RC0
> >
> >  ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y
> >
> >  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT
> >
> >  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN
> >
> >  ICE750I 0 DC 10419394794 TC 0 CS DSVUU KSZ 20 VSZ 20
> >
> >  ICE752I 0 FSZ=10419394794 BC  IGN=0 E  AVG=6143 0  WSP=13535205 C
> >  DYN=244621 56664
> >  ICE751I 1 D8-K58148 D4-K59452 EA-K59517 F1-K58148 E8-K70685
> >
> >  ICE090I 0 OUTPUT LRECL = 12285, BLKSIZE = 27998, TYPE = VB
> >
> >  ICE055I 0 INSERT 0, DELETE 1068329
> >
> >  ICE054I 0 RECORDS - IN: 6258994, OUT: 5190665
> >
> >  ICE134I 0 NUMBER OF BYTES SORTED: 7993209593
> >
> >  ICE253I 0 RECORDS SORTED - PROCESSED: 5215434, EXPECTED: 1696417
> >
> >  ICE098I 0 AVERAGE RECORD LENGTH - PROCESSED: 1532, EXPECTED: 6142
> >
> >  ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 245055 , TRACKS USED:
> >145365
> >  ICE199I 0 MEMORY OBJECT USED AS MAIN STORAGE = 0M BYTES
> >
> >  ICE299I 0 MEMORY OBJECT USED AS WORK STORAGE = 0M BYTES
> >
> >  ICE180I 0 HIPERSPACE STORAGE USED = 0K BYTES
> >
> >  ICE188I 0 DATA SPACE STORAGE USED = 0K BYTES
> >
> >  ICE052I 0 END OF DFSORT
> >
> >
> >=== INCL ===
> >
> >1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
> >
> >  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> >E5-K70685 E6-K58148 C4-K58148 E7-K70685
> >  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
> >
> >  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> >EXAMPLES AND MORE
> >  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:54
> ON
> >WED AUG 19, 2020 -
> >0SORT FIELDS=(13,16,CH,A),EQUALS
> > 00190001
> >  SUM FIELDS=NONE
> > 0021
> >  OUTFIL INCLUDE=(191,1,CH,NE,C'M')   DROP M* POLICIES
> >00210001
> >  ICE201I H RECORD TYPE IS V

Re: DFSORT confusion.

[Joe Monk]

What happens if you code the include like this?

OUTFIL INCLUDE=(19,1,CH,EQ,C'ABCDEFGHIJKLNOPQRSTUVWXYZ0123456789')

Joe

On Thu, Aug 20, 2020 at 6:27 AM John McKown 
wrote:

> This is on z/OS 1.12 (sorry). A programmer has run two DFSORT jobs with
> slightly different control statements which both of us think should result
> in the same output. But it does not. One uses the OMIT statement. The other
> uses an OUTFIL with a COND. Both use SUM FIELDS=NONE and EQUALS=YES to
> remove all duplicate keys, keeping the first record. But the output is
> different. The OMIT run has more records. A quick look seems to indicate
> that OMIT is what he really wants. Here are the DFSOFT messages. I just
> can't see why the OMIT has more output. Most likely due to my own lack of
> understanding.
>
> === OMIT ===
>
> 1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
>
>  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> E5-K70685 E6-K58148 C4-K58148 E7-K70685
>  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
>
>  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> EXAMPLES AND MORE
>  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:41 ON
> WED AUG 19, 2020 -
> 0SORT FIELDS=(13,16,CH,A),EQUALS
> 00190001
>  SUM FIELDS=NONE
> 0021
>  OMIT COND=(191,1,CH,EQ,C'M')   DROP M* POLICIES
> 00210001
>  ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
>
>  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> E5-K70685 E6-K58148 C4-K58148 E7-K70685
>  ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
> SELECTED
>  ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
> 27998, TYPE = VB
>  ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)
>
>  ICE156I 0 MAIN STORAGE ABOVE 16MB = (38819828,38819828)
>
>  ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
> ,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
>  ICE128I 0 OPTIONS:
> SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS=Y,LIST=Y,ERET=RC16
> ,MSGDDN=SYSOUT
>  ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
> ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA   ,031),ABCODE=MSG
>  ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109
> ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
>  ICE131I 0 OPTIONS:
> TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64
>
>  ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
>  ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
>  ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
> ,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=0
>  ICE235I 0 OPTIONS: NULLOUT=RC0
>
>  ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y
>
>  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT
>
>  ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN
>
>  ICE750I 0 DC 10419394794 TC 0 CS DSVUU KSZ 20 VSZ 20
>
>  ICE752I 0 FSZ=10419394794 BC  IGN=0 E  AVG=6143 0  WSP=13535205 C
>  DYN=244621 56664
>  ICE751I 1 D8-K58148 D4-K59452 EA-K59517 F1-K58148 E8-K70685
>
>  ICE090I 0 OUTPUT LRECL = 12285, BLKSIZE = 27998, TYPE = VB
>
>  ICE055I 0 INSERT 0, DELETE 1068329
>
>  ICE054I 0 RECORDS - IN: 6258994, OUT: 5190665
>
>  ICE134I 0 NUMBER OF BYTES SORTED: 7993209593
>
>  ICE253I 0 RECORDS SORTED - PROCESSED: 5215434, EXPECTED: 1696417
>
>  ICE098I 0 AVERAGE RECORD LENGTH - PROCESSED: 1532, EXPECTED: 6142
>
>  ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 245055 , TRACKS USED:
> 145365
>  ICE199I 0 MEMORY OBJECT USED AS MAIN STORAGE = 0M BYTES
>
>  ICE299I 0 MEMORY OBJECT USED AS WORK STORAGE = 0M BYTES
>
>  ICE180I 0 HIPERSPACE STORAGE USED = 0K BYTES
>
>  ICE188I 0 DATA SPACE STORAGE USED = 0K BYTES
>
>  ICE052I 0 END OF DFSORT
>
>
> === INCL ===
>
> 1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
>
>  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> E5-K70685 E6-K58148 C4-K58148 E7-K70685
>  ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED
>
>  ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> EXAMPLES AND MORE
>  ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:54 ON
> WED AUG 19, 2020 -
> 0SORT FIELDS=(13,16,CH,A),EQUALS
> 00190001
>  SUM FIELDS=NONE
> 0021
>  OUTFIL INCLUDE=(191,1,CH,NE,C'M')   DROP M* POLICIES
>00210001
>  ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
>
>  ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
> E5-K70685 E6-K58148 C4-K58148 E7-K70685
>  ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
> SELECTED
>  ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
> 27998, TYPE = VB
>  ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)
>
>  ICE156I 0 MAIN STORAGE ABOVE 16MB = (38815751,38815751)
>
>  ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
> ,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
>  ICE128I 0 OPTIONS:
> SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS

Re: DFSORT confusion.

[Billy Ashton]

John, is it possible that some of the duplicate records have a different 
value in 187/191 - sometimes it has 'M', and sometimes something else?


Can you compare the two different output files to see what is different 
(other than the 231 additional records)? Do you know which output set is 
correct?


Billy
-- Original Message --
From: "John McKown" 
To: IBM-MAIN@listserv.ua.edu
Sent: 8/20/2020 7:26:45 AM
Subject: DFSORT confusion.


This is on z/OS 1.12 (sorry). A programmer has run two DFSORT jobs with
slightly different control statements which both of us think should result
in the same output. But it does not. One uses the OMIT statement. The other
uses an OUTFIL with a COND. Both use SUM FIELDS=NONE and EQUALS=YES to
remove all duplicate keys, keeping the first record. But the output is
different. The OMIT run has more records. A quick look seems to indicate
that OMIT is what he really wants. Here are the DFSOFT messages. I just
can't see why the OMIT has more output. Most likely due to my own lack of
understanding.

=== OMIT ===

1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5

 ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
E5-K70685 E6-K58148 C4-K58148 E7-K70685
 ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED

 ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
EXAMPLES AND MORE
 ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:41 ON
WED AUG 19, 2020 -
0SORT FIELDS=(13,16,CH,A),EQUALS
00190001
 SUM FIELDS=NONE
0021
 OMIT COND=(191,1,CH,EQ,C'M')   DROP M* POLICIES
00210001
 ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5

 ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
E5-K70685 E6-K58148 C4-K58148 E7-K70685
 ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
SELECTED
 ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
27998, TYPE = VB
 ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)

 ICE156I 0 MAIN STORAGE ABOVE 16MB = (38819828,38819828)

 ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
 ICE128I 0 OPTIONS:
SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS=Y,LIST=Y,ERET=RC16
,MSGDDN=SYSOUT
 ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA   ,031),ABCODE=MSG
 ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109
,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
 ICE131I 0 OPTIONS:
TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64

 ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
 ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
 ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=0
 ICE235I 0 OPTIONS: NULLOUT=RC0

 ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y

 ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT

 ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN

 ICE750I 0 DC 10419394794 TC 0 CS DSVUU KSZ 20 VSZ 20

 ICE752I 0 FSZ=10419394794 BC  IGN=0 E  AVG=6143 0  WSP=13535205 C
 DYN=244621 56664
 ICE751I 1 D8-K58148 D4-K59452 EA-K59517 F1-K58148 E8-K70685

 ICE090I 0 OUTPUT LRECL = 12285, BLKSIZE = 27998, TYPE = VB

 ICE055I 0 INSERT 0, DELETE 1068329

 ICE054I 0 RECORDS - IN: 6258994, OUT: 5190665

 ICE134I 0 NUMBER OF BYTES SORTED: 7993209593

 ICE253I 0 RECORDS SORTED - PROCESSED: 5215434, EXPECTED: 1696417

 ICE098I 0 AVERAGE RECORD LENGTH - PROCESSED: 1532, EXPECTED: 6142

 ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 245055 , TRACKS USED:
145365
 ICE199I 0 MEMORY OBJECT USED AS MAIN STORAGE = 0M BYTES

 ICE299I 0 MEMORY OBJECT USED AS WORK STORAGE = 0M BYTES

 ICE180I 0 HIPERSPACE STORAGE USED = 0K BYTES

 ICE188I 0 DATA SPACE STORAGE USED = 0K BYTES

 ICE052I 0 END OF DFSORT


=== INCL ===

1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5

 ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
E5-K70685 E6-K58148 C4-K58148 E7-K70685
 ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED

 ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
EXAMPLES AND MORE
 ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:54 ON
WED AUG 19, 2020 -
0SORT FIELDS=(13,16,CH,A),EQUALS
00190001
 SUM FIELDS=NONE
0021
 OUTFIL INCLUDE=(191,1,CH,NE,C'M')   DROP M* POLICIES
   00210001
 ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5

 ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
E5-K70685 E6-K58148 C4-K58148 E7-K70685
 ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
SELECTED
 ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
27998, TYPE = VB
 ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)

 ICE156I 0 MAIN STORAGE ABOVE 16MB = (38815751,38815751)

 ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
 ICE128I 0 OPTIONS:
SI

DFSORT confusion.

[John McKown]

This is on z/OS 1.12 (sorry). A programmer has run two DFSORT jobs with
slightly different control statements which both of us think should result
in the same output. But it does not. One uses the OMIT statement. The other
uses an OUTFIL with a COND. Both use SUM FIELDS=NONE and EQUALS=YES to
remove all duplicate keys, keeping the first record. But the output is
different. The OMIT run has more records. A quick look seems to indicate
that OMIT is what he really wants. Here are the DFSOFT messages. I just
can't see why the OMIT has more output. Most likely due to my own lack of
understanding.

=== OMIT ===

1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5

 ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
E5-K70685 E6-K58148 C4-K58148 E7-K70685
 ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED

 ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
EXAMPLES AND MORE
 ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:41 ON
WED AUG 19, 2020 -
0SORT FIELDS=(13,16,CH,A),EQUALS
00190001
 SUM FIELDS=NONE
0021
 OMIT COND=(191,1,CH,EQ,C'M')   DROP M* POLICIES
00210001
 ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5

 ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
E5-K70685 E6-K58148 C4-K58148 E7-K70685
 ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
SELECTED
 ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
27998, TYPE = VB
 ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)

 ICE156I 0 MAIN STORAGE ABOVE 16MB = (38819828,38819828)

 ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
 ICE128I 0 OPTIONS:
SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS=Y,LIST=Y,ERET=RC16
,MSGDDN=SYSOUT
 ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA   ,031),ABCODE=MSG
 ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109
,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
 ICE131I 0 OPTIONS:
TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64

 ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
 ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
 ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX
,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=0
 ICE235I 0 OPTIONS: NULLOUT=RC0

 ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y

 ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT

 ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN

 ICE750I 0 DC 10419394794 TC 0 CS DSVUU KSZ 20 VSZ 20

 ICE752I 0 FSZ=10419394794 BC  IGN=0 E  AVG=6143 0  WSP=13535205 C
 DYN=244621 56664
 ICE751I 1 D8-K58148 D4-K59452 EA-K59517 F1-K58148 E8-K70685

 ICE090I 0 OUTPUT LRECL = 12285, BLKSIZE = 27998, TYPE = VB

 ICE055I 0 INSERT 0, DELETE 1068329

 ICE054I 0 RECORDS - IN: 6258994, OUT: 5190665

 ICE134I 0 NUMBER OF BYTES SORTED: 7993209593

 ICE253I 0 RECORDS SORTED - PROCESSED: 5215434, EXPECTED: 1696417

 ICE098I 0 AVERAGE RECORD LENGTH - PROCESSED: 1532, EXPECTED: 6142

 ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 245055 , TRACKS USED:
145365
 ICE199I 0 MEMORY OBJECT USED AS MAIN STORAGE = 0M BYTES

 ICE299I 0 MEMORY OBJECT USED AS WORK STORAGE = 0M BYTES

 ICE180I 0 HIPERSPACE STORAGE USED = 0K BYTES

 ICE188I 0 DATA SPACE STORAGE USED = 0K BYTES

 ICE052I 0 END OF DFSORT


=== INCL ===

1ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5

 ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
E5-K70685 E6-K58148 C4-K58148 E7-K70685
 ICE143I 0 BLOCKSET SORT  TECHNIQUE SELECTED

 ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
EXAMPLES AND MORE
 ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 13:54 ON
WED AUG 19, 2020 -
0SORT FIELDS=(13,16,CH,A),EQUALS
00190001
 SUM FIELDS=NONE
0021
 OUTFIL INCLUDE=(191,1,CH,NE,C'M')   DROP M* POLICIES
   00210001
 ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5

 ICE751I 0 C5-K62149 C6-K90026 C7-K58148 C8-K67572 E9-K60824 C9-BASE
E5-K70685 E6-K58148 C4-K58148 E7-K70685
 ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT
SELECTED
 ICE088I 0 APH893GI.PS050   ., INPUT LRECL = 12285, BLKSIZE =
27998, TYPE = VB
 ICE093I 0 MAIN STORAGE = (MAX,38877188,38877188)

 ICE156I 0 MAIN STORAGE ABOVE 16MB = (38815751,38815751)

 ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0
,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
 ICE128I 0 OPTIONS:
SIZE=38877188,MAXLIM=1048576,MINLIM=450560,EQUALS=Y,LIST=Y,ERET=RC16
,MSGDDN=SYSOUT
 ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO
,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA   ,031),ABCODE=MSG
 ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109
,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
 ICE131I 0 OPTIONS:
TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64

 ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,E