Re: Identifying PDS/E or PDS in IEBCOPY Unload
W dniu 29.07.2021 o 22:50, Paul Gilmartin pisze: On Thu, 29 Jul 2021 15:47:45 -0400, John Abell wrote: Why not have them use TSO XMIT files like we do? Will RECEIVE then allocate (NEW,CATLG) a data set with suitable DSNTYPE, SPACE, RECFM, LRECL, ... If the original PDS is large, is there a problem of overflow of a temporary data set? Please, define large. Personally I used XMIT for 500+ MB PDS. The only issue to remember is IND$FILE parameters, however space can be specified. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identifying PDS/E or PDS in IEBCOPY Unload
To summarize: 1. Not everything can be copied between PDS and PDSE (and vice versa). Notable examples are program objects, long member names, PDSE v2 member versions, etc. 2. Despite other possible options there is no harm to read from PDSU to original PO dataset flavour and then optionally copy it to desired/other flavour. Having in mind restrictions described above. Am I missing something? -- Radoslaw Skorupka Lodz, Poland W dniu 30.07.2021 o 02:37, Billy Ashton pisze: Steve, this is from the IEBCOPY doc: A load module from an unload data set cannot be reloaded into a PDSE as a program object. The load modules should be reloaded into a partitioned data set and then the partitioned data set should be copied to a PDSE to convert the unloaded load module into a program object. This means if a loadlib PDS is unloaded by IEBCOPY, it cannot be loaded directly back into a PDSE as executable modules. I haven't found the doc on it, but it is my understanding that a PDS cannot contain program objects, so if a PDSE is unloaded by IEBCOPY, it cannot be loaded directly back into a PDS. Or am I misreading something here? Don't forget that I am working only with the unloaded file sent to me via FTP, and I do not have the original PDS or PDSE available to me to do things like a 3.3 copy. B Steve Smith wrote on 7/29/2021 18:31: Where did you get that notion? IEBCOPY can indeed load into a dataset of a different type than the source. Only exception I know of is from a PDSE with long aliases. I'd think your "backup plan" (albeit my first plan), would be to unload the file into a PDSE and not worry about it until something goes wrong. sas On Thu, Jul 29, 2021 at 6:07 PM Billy Ashton wrote: These are solution files that the vendor sends to us, so we have no control of what to do. They tell us that the target is a PDS or PDSE, but I was just looking for a backup method to try and ensure that what they say matches the file. As I'm sure you know, if they unloaded a PDS file with load modules, you can't take the unloaded file and then try to load it into a PDSE. Likewise, if a PDSE with program objects was unloaded, you can't load it into a standard PDS. Billy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identifying PDS/E or PDS in IEBCOPY Unload
Multi-step, but universal - you can transfer any number of files and any file type. Small assumption: both sides do have DSS. I use it for VSAM files. Personally I created small REXX tool which read list of PDS/PDSE and PS datasets to transport, then XMIT them, then copy them to big PDS, then XMIT the PDS to sigle FB 80 PS. Advantage: nested XMITed files can be browsed on PC. -- Radoslaw Skorupka Lodz, Poland W dniu 29.07.2021 o 23:25, Tom Brennan pisze: And maybe combinations! I seem to remember doing this one time, working with what was available: DFDSS full volume dump XMIT IND$FILE Thumb drive transfer IND$FILE RECEIVE DFDSS restore On 7/29/2021 2:13 PM, Lizette Koehler wrote: I guess it will depend on what you are trying to accomplish There could be many solutions besides IEBCOPY You can use DFDSS DUMP/RESTORE function to take it as is and restore it as is You can use TSO XMIT (but your shop may limit how many records you can off load If it does use TSO XMIT Dataset(name here) OUTDSN(transmission dataset) Then use your favorite transfer Program (FTP, Fillezilla, etc) to move to new home then receive You might be able to use TRSMAIN Pack/Unpack - I think it handles PDS Datasets now There could be other vendor products that can do this as well What problem are you trying to solve by knowing PDS vs PDSe datasets? I rarely care any more what they are. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identifying PDS/E or PDS in IEBCOPY Unload
Thanks... My mistake - I found my old notes and they mention a Program Object version number, not PDSE version. So maybe that makes more sense. During an attempt to IEBCOPY from PDSE to PDS most load members copied fine, but some newer members failed with: IEW2606S 4B39 MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND CANNOT BE SAVED IN LOAD MODULE FORMAT. The client wanted to change the ASM code that called IEBCOPY to check the source module version before the copy attempt, in order to issue a nicer error message. That's why I went looking for the version number in the module itself. I do remember finding it pretty easily and asked IBM if it was the correct byte and they said yes. On 7/29/2021 9:18 PM, Steve Smith wrote: There are PDSE V1 and V2. Never was sure why IBM decided to do that. There's no significant external difference other than only V2 supports member generations. IEBCOPY's unload file format is documented fairly well in an appendix of the Dataset Utilities manual. I think you were looking at flags, not a number as such. sas On Thu, Jul 29, 2021 at 7:00 PM Tom Brennan wrote: Do PDSE's have format version numbers? I remember (2015) looking at a problem where IEBCOPY would not copy what I think IBM called a V3 PDSE member, and that failure could be predicted by looking at a byte pretty close to the front of the member data (or maybe it was the dir entry) that was x'02' (copied ok) or x'03' (wouldn't copy to a standard PDS). That was right around the time COBOL started requiring PDSE's and I assumed it was like you say, for long name support. -- 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: Identifying PDS/E or PDS in IEBCOPY Unload
There are PDSE V1 and V2. Never was sure why IBM decided to do that. There's no significant external difference other than only V2 supports member generations. IEBCOPY's unload file format is documented fairly well in an appendix of the Dataset Utilities manual. I think you were looking at flags, not a number as such. sas On Thu, Jul 29, 2021 at 7:00 PM Tom Brennan wrote: > Do PDSE's have format version numbers? I remember (2015) looking at a > problem where IEBCOPY would not copy what I think IBM called a V3 PDSE > member, and that failure could be predicted by looking at a byte pretty > close to the front of the member data (or maybe it was the dir entry) > that was x'02' (copied ok) or x'03' (wouldn't copy to a standard PDS). > That was right around the time COBOL started requiring PDSE's and I > assumed it was like you say, for long name support. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identifying PDS/E or PDS in IEBCOPY Unload
No, I got that wrong. I should have read the manual instead of relying on memory, or maybe assumptions. I do cross-load/unloads from time-to-time, but they must all be non-executables. Still, it seems like an odd hole in IEBCOPY's functionality. sas On Thu, Jul 29, 2021 at 8:37 PM Billy Ashton wrote: > Steve, this is from the IEBCOPY doc: > A load module from an unload data set cannot be reloaded into a PDSE as > a program object. The load modules should be reloaded into a partitioned > data set and then the partitioned data set should be copied to a PDSE to > convert the unloaded load module into a program object. > > This means if a loadlib PDS is unloaded by IEBCOPY, it cannot be loaded > directly back into a PDSE as executable modules. I haven't found the doc > on it, but it is my understanding that a PDS cannot contain program > objects, so if a PDSE is unloaded by IEBCOPY, it cannot be loaded > directly back into a PDS. > > Or am I misreading something here? Don't forget that I am working only > with the unloaded file sent to me via FTP, and I do not have the > original PDS or PDSE available to me to do things like a 3.3 copy. > B > > Steve Smith wrote on 7/29/2021 18:31: > > Where did you get that notion? IEBCOPY can indeed load into a dataset > of a > > different type than the source. Only exception I know of is from a PDSE > > with long aliases. > > > > I'd think your "backup plan" (albeit my first plan), would be to unload > the > > file into a PDSE and not worry about it until something goes wrong. > > > > sas > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identifying PDS/E or PDS in IEBCOPY Unload
If you don't pre-allocate then RECEIVE will allocate the target with the proper type. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Thursday, July 29, 2021 4:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Identifying PDS/E or PDS in IEBCOPY Unload On Thu, 29 Jul 2021 15:47:45 -0400, John Abell wrote: >Why not have them use TSO XMIT files like we do? > Will RECEIVE then allocate (NEW,CATLG) a data set with suitable DSNTYPE, SPACE, RECFM, LRECL, ... If the original PDS is large, is there a problem of overflow of a temporary data set? But does the OP control the unload process, or is he given an unloaded PDS(E) and tasked with reloading it? -- 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: Identifying PDS/E or PDS in IEBCOPY Unload
Steve, this is from the IEBCOPY doc: A load module from an unload data set cannot be reloaded into a PDSE as a program object. The load modules should be reloaded into a partitioned data set and then the partitioned data set should be copied to a PDSE to convert the unloaded load module into a program object. This means if a loadlib PDS is unloaded by IEBCOPY, it cannot be loaded directly back into a PDSE as executable modules. I haven't found the doc on it, but it is my understanding that a PDS cannot contain program objects, so if a PDSE is unloaded by IEBCOPY, it cannot be loaded directly back into a PDS. Or am I misreading something here? Don't forget that I am working only with the unloaded file sent to me via FTP, and I do not have the original PDS or PDSE available to me to do things like a 3.3 copy. B Steve Smith wrote on 7/29/2021 18:31: Where did you get that notion? IEBCOPY can indeed load into a dataset of a different type than the source. Only exception I know of is from a PDSE with long aliases. I'd think your "backup plan" (albeit my first plan), would be to unload the file into a PDSE and not worry about it until something goes wrong. sas On Thu, Jul 29, 2021 at 6:07 PM Billy Ashton wrote: These are solution files that the vendor sends to us, so we have no control of what to do. They tell us that the target is a PDS or PDSE, but I was just looking for a backup method to try and ensure that what they say matches the file. As I'm sure you know, if they unloaded a PDS file with load modules, you can't take the unloaded file and then try to load it into a PDSE. Likewise, if a PDSE with program objects was unloaded, you can't load it into a standard PDS. Billy -- 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: Identifying PDS/E or PDS in IEBCOPY Unload
Do PDSE's have format version numbers? I remember (2015) looking at a problem where IEBCOPY would not copy what I think IBM called a V3 PDSE member, and that failure could be predicted by looking at a byte pretty close to the front of the member data (or maybe it was the dir entry) that was x'02' (copied ok) or x'03' (wouldn't copy to a standard PDS). That was right around the time COBOL started requiring PDSE's and I assumed it was like you say, for long name support. On 7/29/2021 3:31 PM, Steve Smith wrote: Where did you get that notion? IEBCOPY can indeed load into a dataset of a different type than the source. Only exception I know of is from a PDSE with long aliases. I'd think your "backup plan" (albeit my first plan), would be to unload the file into a PDSE and not worry about it until something goes wrong. sas On Thu, Jul 29, 2021 at 6:07 PM Billy Ashton wrote: These are solution files that the vendor sends to us, so we have no control of what to do. They tell us that the target is a PDS or PDSE, but I was just looking for a backup method to try and ensure that what they say matches the file. As I'm sure you know, if they unloaded a PDS file with load modules, you can't take the unloaded file and then try to load it into a PDSE. Likewise, if a PDSE with program objects was unloaded, you can't load it into a standard PDS. Billy -- 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: Identifying PDS/E or PDS in IEBCOPY Unload
Where did you get that notion? IEBCOPY can indeed load into a dataset of a different type than the source. Only exception I know of is from a PDSE with long aliases. I'd think your "backup plan" (albeit my first plan), would be to unload the file into a PDSE and not worry about it until something goes wrong. sas On Thu, Jul 29, 2021 at 6:07 PM Billy Ashton wrote: > These are solution files that the vendor sends to us, so we have no > control of what to do. They tell us that the target is a PDS or PDSE, > but I was just looking for a backup method to try and ensure that what > they say matches the file. As I'm sure you know, if they unloaded a PDS > file with load modules, you can't take the unloaded file and then try to > load it into a PDSE. Likewise, if a PDSE with program objects was > unloaded, you can't load it into a standard PDS. > Billy > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identifying PDS/E or PDS in IEBCOPY Unload
These are solution files that the vendor sends to us, so we have no control of what to do. They tell us that the target is a PDS or PDSE, but I was just looking for a backup method to try and ensure that what they say matches the file. As I'm sure you know, if they unloaded a PDS file with load modules, you can't take the unloaded file and then try to load it into a PDSE. Likewise, if a PDSE with program objects was unloaded, you can't load it into a standard PDS. Billy John Abell wrote on 7/29/2021 15:47: Why not have them use TSO XMIT files like we do? John T. Abell Tel:800-295-7608Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax:800-295-7609 International: 1-416-593-5579 International Software Products www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Billy Ashton Sent: Thursday, July 29, 2021 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Identifying PDS/E or PDS in IEBCOPY Unload Hey everyone, here is an odd question for y'all. Is there any way I can tell from an IEBCOPY unload file (that I received from a vendor) whether it is an unload of a PDS or an unload of a PDS/E? Since IEBCOPY is pretty particular about only loading full libraries back to the same source type, I was hoping I could look at byte 42 or something like that to know that I need to load this to a PDS/E. Anybody have any hope for me here? (I know I can ask the vendor, but I wanted to confirm programmatically if possible). Billy -- 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: Identifying PDS/E or PDS in IEBCOPY Unload
And maybe combinations! I seem to remember doing this one time, working with what was available: DFDSS full volume dump XMIT IND$FILE Thumb drive transfer IND$FILE RECEIVE DFDSS restore On 7/29/2021 2:13 PM, Lizette Koehler wrote: I guess it will depend on what you are trying to accomplish There could be many solutions besides IEBCOPY You can use DFDSS DUMP/RESTORE function to take it as is and restore it as is You can use TSO XMIT (but your shop may limit how many records you can off load If it does use TSO XMIT Dataset(name here) OUTDSN(transmission dataset) Then use your favorite transfer Program (FTP, Fillezilla, etc) to move to new home then receive You might be able to use TRSMAIN Pack/Unpack - I think it handles PDS Datasets now There could be other vendor products that can do this as well What problem are you trying to solve by knowing PDS vs PDSe datasets? I rarely care any more what they are. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Billy Ashton Sent: Thursday, July 29, 2021 11:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Identifying PDS/E or PDS in IEBCOPY Unload Hey everyone, here is an odd question for y'all. Is there any way I can tell from an IEBCOPY unload file (that I received from a vendor) whether it is an unload of a PDS or an unload of a PDS/E? Since IEBCOPY is pretty particular about only loading full libraries back to the same source type, I was hoping I could look at byte 42 or something like that to know that I need to load this to a PDS/E. Anybody have any hope for me here? (I know I can ask the vendor, but I wanted to confirm programmatically if possible). Billy -- 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: Identifying PDS/E or PDS in IEBCOPY Unload
I guess it will depend on what you are trying to accomplish There could be many solutions besides IEBCOPY You can use DFDSS DUMP/RESTORE function to take it as is and restore it as is You can use TSO XMIT (but your shop may limit how many records you can off load If it does use TSO XMIT Dataset(name here) OUTDSN(transmission dataset) Then use your favorite transfer Program (FTP, Fillezilla, etc) to move to new home then receive You might be able to use TRSMAIN Pack/Unpack - I think it handles PDS Datasets now There could be other vendor products that can do this as well What problem are you trying to solve by knowing PDS vs PDSe datasets? I rarely care any more what they are. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Billy Ashton Sent: Thursday, July 29, 2021 11:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Identifying PDS/E or PDS in IEBCOPY Unload Hey everyone, here is an odd question for y'all. Is there any way I can tell from an IEBCOPY unload file (that I received from a vendor) whether it is an unload of a PDS or an unload of a PDS/E? Since IEBCOPY is pretty particular about only loading full libraries back to the same source type, I was hoping I could look at byte 42 or something like that to know that I need to load this to a PDS/E. Anybody have any hope for me here? (I know I can ask the vendor, but I wanted to confirm programmatically if possible). Billy -- 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: Identifying PDS/E or PDS in IEBCOPY Unload
On Thu, 29 Jul 2021 15:47:45 -0400, John Abell wrote: >Why not have them use TSO XMIT files like we do? > Will RECEIVE then allocate (NEW,CATLG) a data set with suitable DSNTYPE, SPACE, RECFM, LRECL, ... If the original PDS is large, is there a problem of overflow of a temporary data set? But does the OP control the unload process, or is he given an unloaded PDS(E) and tasked with reloading it? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identifying PDS/E or PDS in IEBCOPY Unload
Why not have them use TSO XMIT files like we do? John T. Abell Tel:800-295-7608Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax:800-295-7609 International: 1-416-593-5579 International Software Products www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Billy Ashton Sent: Thursday, July 29, 2021 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Identifying PDS/E or PDS in IEBCOPY Unload Hey everyone, here is an odd question for y'all. Is there any way I can tell from an IEBCOPY unload file (that I received from a vendor) whether it is an unload of a PDS or an unload of a PDS/E? Since IEBCOPY is pretty particular about only loading full libraries back to the same source type, I was hoping I could look at byte 42 or something like that to know that I need to load this to a PDS/E. Anybody have any hope for me here? (I know I can ask the vendor, but I wanted to confirm programmatically if possible). Billy -- 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: Identifying PDS/E or PDS in IEBCOPY Unload
> Is there any way I can tell from an IEBCOPY unload file (that I received Billy, You can print the header record of the unloaded IEBCOPY and check for Bit 7 whether the input dataset is a PDSE or NOT. Here is the lay out the header record from IEBCOPY https://www.ibm.com/docs/en/zos/2.4.0?topic=descriptions-header-records //CHKHDR EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //INP DD DISP=SHR,DSN=your unloaded.Iebcopy.dsn //SYSINDD * PRINT INFILE(INP) COUNT(1) /* Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identifying PDS/E or PDS in IEBCOPY Unload
I don't think you would have any issues unloading it as PDSE. I've used IEBCOPY to convert from PDS to PDSE. Use COPYMOD if it's a load. //COPYN0 EXEC PGM=IEBCOPY,COND=(0,NE) //SYSPRINT DD SYSOUT=* //SYSUT1 DD DSN=&NEW,DISP=SHR //SYSUT2 DD DSN=&OLD, // DISP=(NEW,CATLG,DELETE), // DSNTYPE=LIBRARY, // UNIT=SYSDA, // DCB=(RECFM=U,LRECL=0,BLKSIZE=32760), // SPACE=(CYL,(233,50,500)) //SYSIN DD * COPYMOD OUTDD=SYSUT2,INDD=SYSUT1 EXCLUDE MEMBER=$$$SPACE /* Manuel Seguin Information Technology Specialist Programming SECURITY ARCHITECTURE Office of Information Technology Services W.A. Harriman Campus, Building 8, 7th floor, Cube 113 Albany NY 12227 (518) 473-4002 ITSM L2 RT-BUS SYS SECURITY DTF Group DL tax.dl.OnLine-Systems manuel.seg...@its.ny.gov www.its.ny.gov -Original Message- From: IBM Mainframe Discussion List On Behalf Of Billy Ashton Sent: Thursday, July 29, 2021 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Identifying PDS/E or PDS in IEBCOPY Unload ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Hey everyone, here is an odd question for y'all. Is there any way I can tell from an IEBCOPY unload file (that I received from a vendor) whether it is an unload of a PDS or an unload of a PDS/E? Since IEBCOPY is pretty particular about only loading full libraries back to the same source type, I was hoping I could look at byte 42 or something like that to know that I need to load this to a PDS/E. Anybody have any hope for me here? (I know I can ask the vendor, but I wanted to confirm programmatically if possible). Billy -- 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
Identifying PDS/E or PDS in IEBCOPY Unload
Hey everyone, here is an odd question for y'all. Is there any way I can tell from an IEBCOPY unload file (that I received from a vendor) whether it is an unload of a PDS or an unload of a PDS/E? Since IEBCOPY is pretty particular about only loading full libraries back to the same source type, I was hoping I could look at byte 42 or something like that to know that I need to load this to a PDS/E. Anybody have any hope for me here? (I know I can ask the vendor, but I wanted to confirm programmatically if possible). Billy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
