Re: DFSORT ICE085A - Options?

[Martin Packer]

Was it a single IFTHEN?

Also, I suppose that IFTHEN, being relatively new, might’ve had a different
implementation. But I don’t know and I doubt this kind of internal is
something Sri Hari would feel free to talk about.

Sent from my iPad

> On 4 Apr 2019, at 00:08, van der Grijn, Bart (B) 
wrote:
>
> Thanks all for the comments and advice. My issue is resolved, but I don't
yet understand why.
>
> A big thanks to Kolusu. I took him up on his offer and sent him the
relevant data offline. He produced a solution that looks as follows
(apologies if the formatting gets messed up):
>
> My original control cards:
>  OPTION COPY,NOVLSHRT,
>  OUTFIL FNAMES=OUT,VTOF,OUTREC=(ASEGAR,
>  C'|',
> ...
> 
> ...
>  C'|',
>  AFRE98)
>
> Kolusu's solution:
>  OPTION COPY
>  INREC IFTHEN=(WHEN=INIT,
>BUILD=(RDW,
>   ASEGAR,
> C'|',
> ...
> 
> ...
> C'|',
> AFRE98))
>  OUTFIL VTOF,BUILD=(5,5090)
>
> This solved my problem and was a simple fix to implement in the REXX that
generates the control cards.
>
> In addition he pointed out that my edit masks needed some work as I had a
lot of
> EDIT=(I.II)
> types of masks that should have been
> EDIT=(T.TT)
>
> So while my issue is resolved, I do wonder what the magic here is.
Reviewing the manual on INREC IFTHEN(WHEN=INIT it suggests there's no
actual functionality to this for the sort statement I have. However,
removing this and just using INREC BUILD resulted in the same ICE085A
problem.
> So what's the logic here with regards to IFTHEN and memory usage?
>
> Thanks,
> Bart
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Sri h Kolusu
> Sent: Tuesday, April 02, 2019 1:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT ICE085A - Options?
>
>>> There are 473 input fields that are copied over, some of them
converted,
> with '|' inserted as separator.
> Bart,
>
> That is one too many edit fields.  Looks like you have an input file and
> want to convert it to pipe delimited file. If you can send me a sample
> input file and the symbol mapping along with control cards, then I
probably
> might be able to come up with something ( No promises though)
>
> 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
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: z114 and z/OS 2.3

[Jim Stefanik]

The documentation is correct. Anything older than EC12 (or BC12) will drop to a 
wait state. I've tried it on a z196 and almost instantly get a wait.



---

Jim Stefanik
Dallas Vintage Computing Center

From: Christian Svensson <022ad63487ef-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, 3 April 2019 22:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z114 and z/OS 2.3

Hi, 

I know that z114 is not officially supported on z/OS 2.3 - but I was 
wondering if anyone has had any success IPLing it just for experimental 
purposes on this platform? 

I see that the wait state documentation for z/OS 2.3 wait state 07B says 
that "Miscellaneous-instruction-extension facility" is required and that 
appears to have been added arch-level 10 

 
and 
z114 is arch-level 9. The other facilities appears to be present in z114. 

Still, I wonder if this is reflective of the reality. 
Does anyone on the list have any real life confirmations that it will 
indeed blow up in my face if I try it? 

Thanks, 

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

z114 and z/OS 2.3

[Christian Svensson]

Hi,

I know that z114 is not officially supported on z/OS 2.3 - but I was
wondering if anyone has had any success IPLing it just for experimental
purposes on this platform?

I see that the wait state documentation for z/OS 2.3 wait state 07B says
that "Miscellaneous-instruction-extension facility" is required and that
appears to have been added arch-level 10

and
z114 is arch-level 9. The other facilities appears to be present in z114.

Still, I wonder if this is reflective of the reality.
Does anyone on the list have any real life confirmations that it will
indeed blow up in my face if I try it?

Thanks,

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

Re: AMODE 32

[Mike Schwab]

z/OS is already using the 2GiB to 4GiB area.

On Wed, Apr 3, 2019 at 7:51 PM Paul Edwards  wrote:
>
> On Wed, 3 Apr 2019 19:38:02 -0500, Paul Gilmartin  
> wrote:
>
> >>I was thinking that z/Arch and z/OS could
> >>be updated to support AMODE 32.
>
> >Cui bono?
>
> Combined with making GETMAIN LOC=ANY,
> when executed AM32, getting memory in the
> 2 GiB to 4 GiB region, it would allow a long
> term plan of having purely 32-bit and purely
> 64-bit software running on z/OS, with access
> to the full address space, the same as other
> platforms have. AM24 and AM31 software
> can be phased out.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: AMODE 32

[Paul Edwards]

On Wed, 3 Apr 2019 19:38:02 -0500, Paul Gilmartin  wrote:

>>I was thinking that z/Arch and z/OS could
>>be updated to support AMODE 32.

>Cui bono?

Combined with making GETMAIN LOC=ANY,
when executed AM32, getting memory in the
2 GiB to 4 GiB region, it would allow a long
term plan of having purely 32-bit and purely
64-bit software running on z/OS, with access
to the full address space, the same as other
platforms have. AM24 and AM31 software
can be phased out.

BFN. Paul.

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

Re: AMODE 32

[Paul Gilmartin]

On Wed, 3 Apr 2019 18:17:46 -0500, Paul Edwards wrote:

>I was thinking that z/Arch and z/OS could
>be updated to support AMODE 32.
> 
Cui bono?

Actually, Java uses 32-bit addressing.  In a way.  Simulated.

-- gil

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

AMODE 32

[Paul Edwards]

I was thinking that z/Arch and z/OS could
be updated to support AMODE 32.

If a load module is marked AMODE ANY,
RMODE ANY it could signify that it is
32-bit clean. That combination is
currently not really used, and the linker
can be updated to accept this combination.

PSW bit 30 can be used to signify that an
application is running AM32.

The BSM instruction can use bit x'4000 '
to get/set AM32. This introduces a 1 GiB
restriction where the module should not
be loaded above if it needs to switch
AMODEs to call READ etc. But that's another
restriction that could be lifted in z/OS.
z/OS can instead switch to AM31 itself,
with the READ code being located below 1 GiB.

BFN. Paul.

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

Re: DFSORT ICE085A - Options?

[van der Grijn, Bart (B)]

Thanks all for the comments and advice. My issue is resolved, but I don't yet 
understand why.

A big thanks to Kolusu. I took him up on his offer and sent him the relevant 
data offline. He produced a solution that looks as follows (apologies if the 
formatting gets messed up): 

My original control cards: 
  OPTION COPY,NOVLSHRT,
  OUTFIL FNAMES=OUT,VTOF,OUTREC=(ASEGAR,
  C'|', 
...

...
  C'|',
  AFRE98)  

Kolusu's solution: 
  OPTION COPY
  INREC IFTHEN=(WHEN=INIT,
BUILD=(RDW,
   ASEGAR,
 C'|',
...

...
 C'|',
 AFRE98))
  OUTFIL VTOF,BUILD=(5,5090)

This solved my problem and was a simple fix to implement in the REXX that 
generates the control cards. 

In addition he pointed out that my edit masks needed some work as I had a lot 
of 
EDIT=(I.II) 
types of masks that should have been 
EDIT=(T.TT) 

So while my issue is resolved, I do wonder what the magic here is. Reviewing 
the manual on INREC IFTHEN(WHEN=INIT it suggests there's no actual 
functionality to this for the sort statement I have. However, removing this and 
just using INREC BUILD resulted in the same ICE085A problem. 
So what's the logic here with regards to IFTHEN and memory usage? 

Thanks,
Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Tuesday, April 02, 2019 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT ICE085A - Options?

>>There are 473 input fields that are copied over, some of them converted,
with '|' inserted as separator.
Bart,

That is one too many edit fields.  Looks like you have an input file and
want to convert it to pipe delimited file. If you can send me a sample
input file and the symbol mapping along with control cards, then I probably
might be able to come up with something ( No promises though)

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

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

Re: When is an automatic DETACH issued for an IARV64 SHAREMEMOBJ?

[Steve Partlow]

The SHAREMEMOBJ is cleaned up at address space termination (or if explicitly 
detached with AFFINITY=LOCAL). GETSHARED requests are never automatically 
cleaned up and must be explicitly detached with AFFINITY=SYSTEM. The memory is 
finally freed when all local and system requests have detached (explicitly or 
automatically).

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

The 64-bit version of LOOK from CBT File 264 is finally out

[Sam Golob]

Hi Folks,

    I'm happy to announce that the 64-bit version of the LOOK program 
from CBT File 264 is finally out, on the Updates page of 
www.cbttape.org.  It has been a long time in coming.


    Now you can browse virtual storage and and navigate control blocks 
in all three:  64-bit, 31-bit, and 24-bit storage, and in ANY ADDRESS SPACE.


    I know that many of you have other ways of doing this, but the 
64-bit LOOK command, named LOOKN to distinguish it from the 31-bit 
version, has been a mainstay for many programmers, and for me.


    My friend Joe Reichman did most of the development, and he 
modernized many parts of the program:  SCHEDULE was replaced by IEAMSCHD 
in synchronous mode, and much more was revamped by Joe, including recovery.


    Right now I think that LOOKN works very nicely, switching back and 
forth between 64-bit and 31-bit storage and so forth. But I'd like the 
people to use it, beat it up, and report any problems to me, so we can 
fix them.  LOOK does not change storage.  It gives you the opportunity 
to see the data you're programming for.


    The old versions of LOOK are still around on File 264, so that 
folks using pre-z/OS systems can still have a their source codes.


    All the best of everything to all of you.

Sincerely,    Sam

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

Re: Extended format datasets

[R.S.]

W dniu 2019-04-03 o 14:49, Lennie Dymoke-Bradshaw pisze:

Can anyone point me to documentation showing the internal differences between 
basic format and extended format datasets?


It is undocumented (in publicly available documentation).
All we know is:
EF must be SMS-managed
EF must be allocated on 3990 CU or so. (or newer - nowadays it's hard to 
find unsupported device)

EF can have up to 123 extents per volume
Every block of EF file has 1 cell added. For 3390 it is 34 bytes, but 
only 32 bytes are used (compatibility with 3380). BTW: you can view the 
content of the cell, but it's content and purpose remains secret.

EF PS can be compressed or encrypted.
EF can be PS or VSAM (all 5 flavours), but some features like 
compression are not for all types (only PS and partially KSDS can be 
compressed).
There are some features available for VSAM EF, usually not applicable 
for PS.


AFAIK there is a limit of blocks in EF PS file, but nowadays volume 
limits works first, so it's theroretical.


Oh, in z/OS 2 new format of EF was introduced. Difference? Unknown.

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: Pervasive encryption and batch temporary datasets

[Allan Staller]

Encryption is good (if properly used), buzzwords are buzzwords.

Agreed!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Wednesday, April 3, 2019 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Pervasive encryption and batch temporary datasets

W dniu 2019-04-02 o 14:59, Allan Staller pisze:
> Let me try it this way.
>
> Is df/SMS encryption a pre-requisite to the z/14 "PERVASIVE ENCRYPTION"?

DFSMS encryption is technical feature, which apply to selected kinds of 
datasets.

Pervasive Encryption is a buzzword which means nothing special except 
"mainframes can encrypt many things which other platform cannot".
Despite of sense and reason of such encryption.

Encryption is good (if properly used), buzzwords are buzzwords.

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,https://apc01.safelinks.protection.outlook.com/?url=www.mBank.pl&data=02%7C01%7Callan.staller%40HCL.COM%7Cc1e0687c5e8b4ed2a85f08d6b84bba24%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636899032745149851&sdata=Rj%2FTagP8K4mfAI7WMbYC4I2m5auFJPbT58yipBcTlP4%3D&reserved=0,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,https://apc01.safelinks.protection.outlook.com/?url=www.mBank.pl&data=02%7C01%7Callan.staller%40HCL.COM%7Cc1e0687c5e8b4ed2a85f08d6b84bba24%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636899032745149851&sdata=Rj%2FTagP8K4mfAI7WMbYC4I2m5auFJPbT58yipBcTlP4%3D&reserved=0,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 
January 2018.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Pervasive encryption and batch temporary datasets

[R.S.]

W dniu 2019-04-02 o 14:59, Allan Staller pisze:

Let me try it this way.

Is df/SMS encryption a pre-requisite to the z/14 "PERVASIVE ENCRYPTION"?


DFSMS encryption is technical feature, which apply to selected kinds of 
datasets.


Pervasive Encryption is a buzzword which means nothing special except 
"mainframes can encrypt many things which other platform cannot". 
Despite of sense and reason of such encryption.


Encryption is good (if properly used), buzzwords are buzzwords.

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: Extended format datasets

[Martin Packer]

Hi Lennie.

A" standard practice" among developers whose products use EXCP (eg DFSORT) 
is to switch to BSAM in the case of Extended Format.

That might tell you which way the wind is blowing.

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Lennie Dymoke-Bradshaw 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   03/04/2019 16:05
Subject:Re: Extended format datasets
Sent by:IBM Mainframe Discussion List 



Tom,

Thanks. I found this summary only.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/coefsds.htm


I am trying to understand what is going on under the covers. I am also 
trying to understand what programming changes might be needed if a 
customer is using EXCP rather than a standard access method. 
I would also like to know what is the difference between the type 1 and 
type 2 extended data sets.

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf 
Of Tom Marchant
Sent: 03 April 2019 15:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Extended format datasets

On Wed, 3 Apr 2019 07:49:31 -0500, Lennie Dymoke-Bradshaw wrote:

>Can anyone point me to documentation showing the internal differences 
between basic format and extended format datasets?

Did you look in DFSMS: Using Data Sets?

--
Tom Marchant

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: Extended format datasets

[Lennie Dymoke-Bradshaw]

Tom,

Thanks. I found this summary only.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/coefsds.htm

I am trying to understand what is going on under the covers. I am also trying 
to understand what programming changes might be needed if a customer is using 
EXCP rather than a standard access method. 
I would also like to know what is the difference between the type 1 and type 2 
extended data sets.

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: 03 April 2019 15:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Extended format datasets

On Wed, 3 Apr 2019 07:49:31 -0500, Lennie Dymoke-Bradshaw wrote:

>Can anyone point me to documentation showing the internal differences between 
>basic format and extended format datasets?

Did you look in DFSMS: Using Data Sets?

--
Tom Marchant

--
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: Extended format datasets

[Tom Marchant]

On Wed, 3 Apr 2019 07:49:31 -0500, Lennie Dymoke-Bradshaw wrote:

>Can anyone point me to documentation showing the internal differences between 
>basic format and extended format datasets?

Did you look in DFSMS: Using Data Sets?

-- 
Tom Marchant

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

Extended format datasets

[Lennie Dymoke-Bradshaw]

Can anyone point me to documentation showing the internal differences between 
basic format and extended format datasets?
Thanks,
Lennie Dymoke-Bradshaw

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