Re: PDSEv2 and JCL (again!)
Specifying a PDSE member generation in JCL is currently not supported. Tabari -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Two related member generation questions
ISPF supports PDSE member generations via the prompt menu. With this interface the specific member generation can be browsed, edited and even saved as the latest version. On Mon, 29 May 2023 19:10:55 -0500, Charles Mills wrote: >@Steve, thanks. > >>JCL provides no support at all for PDSE member generations. > >Grumble, grumble. What about ISPF? I sure don't see it, but perhaps I am using >a customized ISPF? Or there is some option that is not turned on in the z/OS >that I am using? > >>Support for PDSE as a member* of a GDG was added in z/OS 2.1 or 2, iirc. >>*(not to be confused with members of a PDS[E] > >And also not to be confused with PDSE 2 member generations, right? > >> maybe they could have >> tried harder not to be confusing > >Agreed. > >>note, while GDGs usually consist of "generations" of the same dataset, >>there's no rule that says they must be. > >Interesting. Did not know that. > >Charles > >On Mon, 29 May 2023 19:28:35 -0400, Steve Smith wrote: > >>"GDGs can be members of PDS or PDSE." -I can't even guess what you're >>trying to say, but on the face of it, that's not only wrong, but absurd. >> >>JCL provides no support at all for PDSE member generations. >> >>Support for PDSE as a member* of a GDG was added in z/OS 2.1 or 2, iirc. >>*(not to be confused with members of a PDS[E], but maybe they could have >>tried harder not to be confusing). So, you can have multiple generations > >-- >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: IEBPDSE (was: emptying a PDS ...)
> Yes. That doesn't mean that there are no concurrency issues. (Sorry for the double post) You are correct on the first part. PDSE is aware of any extents that are added to the data set while it is open. This is true both for opens on the same system and opens on different systems within the sysplex, with the latter only enabled with PDSE Extended mode sharing. Tabari -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPDSE (was: emptying a PDS ...)
>Does IEBCOPY copy pending deleted pages? That seems to be bad design >to me. Is it needed for data integrity? IEBCOPY does not copy members that are in pending delete status. >>Does PARM=PERFORMPENDINGDELETE unilaterally force the effect of STOW >DISC in all address spaces? That would seem to violate the intent of >maintaining >member connections. No. It performs pending delete processing, fully removing members in pending delete status which no longer have connections. Tabari -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE Bug with BPXWUNIX ?
In any case, perhaps it is worth adding the _EDC_ADD_ERRNO2 environment variable to help isolate the problem. Tabari Alexander -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE Bug with BPXWUNIX ?
Could this APAR be relevant here? http://www-01.ibm.com/support/docview.wss?crawler=1&uid=isg1OA55684 Tabari Alexander -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS Member updating via COBOL Program
>PDSE data sets and members can be shared. If allocated with DISP=SHR, the >PDSE directory can be shared by multiple writers and readers, and each PDSE >member can be shared by a single writer or multiple readers. Any number of >systems can have the same PDSE open for input. If one system has a PDSE >open for output (to create or replace members), that PDSE can be opened on >other systems only if the systems are using the PDSE extended sharing >protocol. The storage administrator can establish PDSE extended sharing >protocol by using the PDSESHARING keyword in the IGDSMS*xx* member of >SYS1.PARMLIB as described in z/OS DFSMSdfp Storage Administration ><https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idas200/abstract.htm?view=kc> >. One thing that I might add here is that if JOBA is really updating the member, as in opening the member for UPDATE, the PDSE sharing capabilities are diminished as opening a member for UPDATE requires the system to have exclusive access to the data set even if extended sharing is enabled. With that being said, the PDSE can still be shared in this scenario within the same system. --- Tabari Alexander -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE DELETE PENDING
One of the differences between PDSes and PDSEs is that PDSEs reclaim the space of deleted members. In order for that to be done, however, the PDSE address space needs to know that the member is no longer in use so it is safe for the space to be reclaimed. If the space cannot be reclaimed at the time of deletion, which is typical if the PDSE is LLA managed, there are other opportunities where PDSE will try to reclaim the space as part of normal processing. IEBPDSE with the PerformPendingDelete parameter is a means to force the processing to occur. Please do note that this process will still only reclaim space from deleted members that are not in use. Tabari -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS ALLOCATE AND PDSE V2
The documentation for IDCAMS ALLOCATE is incomplete. It does support allocation of PDSE V2 by specifying DSNTYPE(LIBRARY,2). I cannot speak to the behavior of LIKE, however. Tabari -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unresolved external references when trying to link DLL app
> IEW2322I 1220 1IMPORT CODE64,'SYSADATA','openadata__FPc' Based on this statement, can I make the assumption that you are building 64-bit code? > IEW2469E 9907 THE ATTRIBUTES OF A REFERENCE TO CEETEST FROM SECTION SYSADATA > DO Is CEETEST 31-bit or 64-bit? They need to be the same AMODE. > IEW2456E 9207 SYMBOL CEETGTFN UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM > THE > IEW2456E 9207 SYMBOL CEEINT UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM > THE D > IEW2456E 9207 SYMBOL CEESTART UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM > THE > IEW2456E 9207 SYMBOL CEEBETBL UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM > THE > IEW2456E 9207 SYMBOL CEETREC UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM > THE > IEW2456E 9207 SYMBOL fopen UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM THE > DE You do not have the LE libraries in your SYSLIB concatenation. Please refer to this page https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcux01/finauto.htm to determine which libraries to include. It is dependent on whether or not your code is 31-bit NOXPLINK, 31-bit XPLINK, or 64-bit. > IEW2456E 9207 SYMBOL openadata UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM > TH Dll source code I think you're getting this because you are adding the sidedeck to your bind. This step is not necessary because the DLL that you are building provides openadata, not referencing it. You would add the sidedeck when binding other programs which want to call openadata. > #pragma map(opnadata,"openadata") Typo. You've got opnadata instead of openadata. Keep in mind that you are also mapping it to a name that is longer than 8 characters. You're going to have to enable longname support on the bind to take advantage of that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unresolved external references when trying to link DLL app
Hello, With respect to the unresolved references, have you included the LE libraries in your SYSLIB concatenation? More info can be found here: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ceea200/cllexx.htm >However the most troubling is the C function I exported I included the side >deck which has my exported function >Strangely thought even tough I included a pragma map to leave the name as it >appended _FPC In the snippet you posted, I see where you use a #pragma map to map __ceetest's name. I do not see an equivalent statement for "openadata". >From my understanding the sidedeck would be concatenated to IEWL SYSLIN You are correct. The sidedeck that is created would be concatenated on the IEWL SYSLIN for programs that wish use the DLL. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
