Re: IPCS command to display dataspaces connected to by an arbitral DU
I don't know about the IPCS command, but the DUCT address is in the STCB (and in CR2 while executing). The value in the XSB is used to manage information about the DUCT when, in particular, IRBs are involved. STCBALOV has the virtual address of the DU's access list for a task. There are no programming interfaces in the WEB. No macro is provided. Some information can be found in the Data Areas book. 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: Concatenated datasets
How can one determine where a module is obtained from when the module is in a concatinated dataset list? So for example you want to load module A and your dataset list is: //modules dd disp=shr,dsn=hlq1.ds1 has modules qwert //dd disp=shr,dsn=hlq1.ds2 has modules asdf //dd disp=shr,dsn=hlq2.ds5 has modules zxcv So now you would get in return that module A comes from hlq1.ds2 As has been mentioned, BLDL and DESERV are the answers to the question of "which numbered data set in this concatenation has A?". Finding the data set name itself is more involved (perhaps using a service such as RDJFCB). But is there any way "after the LOAD"? IOW I have already loaded the module and now I want to learn the source. I don't know. Does CSVQUERY or similar return this info? z/OS itself does not, and will not, do anything to capture this information as a general approach when it does the LOAD because z/OS has no need for it and there would be negative performance ramifications of locating the information. Relying on the intentionally undocumented contents of CSVQUERY's OUTPDATA is unwise. That parameter is provided so that the returned data can be input to other services which are in synch with the implementation. If you'd like a hint of something we might document in the future, with data available today, it's the 8 byte data set key (CSVQUERY OUTDSKEY keyword). That consists of a 4-byte UCB address and the CCHH of the data set extent (this is information retrieved from the DEB for the concatenation as identified by BLDL/DESERV). It is possible to work with that data along with additional info (such as the VTOC, I think) and determine the name of the data set. But the OP's use case is not limited to modules. Thus any CSVQUERY information is not helpful in general. So doing it yourself via BLDL/DESERV against the opened concatenation or using the approach Tom Conley mentioned would work. I'd guess that many sites already have some tool that can "locate" within an "opened DD" a member and tell you the data set name in which the member lives. 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: DFSORT - AND/OR mystery
W dniu 30.07.2021 o 19:35, Sri h Kolusu pisze: 3. I found another mystery, which seems to be APARable: But this statement gives zero records. Note, I added "OR" conditions, so it cannot narrow the output. Radoslaw, I would respectfully disagree with that statement. I explained the quirks of having Variable record lengths have on the comparison tests. Use the control cards that I showed and if you are still NOT getting the right results, then please open a case with IBM support. IMHO you wouldn't need that, but just in case ! Sri, Thank you for your explanations. VLSCMP solved the issue. The trick was related to variable length of records. However I sustain that for fixed length (or long enough variable) records adding conditions using OR cannot narrow the output. In other words one cannot less records than before adding conditions. Nevermind, thank you again! -- 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: DFSORT - AND/OR mystery
FWIW, the offset at number 3, second example, 4th line, is 99, not 98. Maybe this is part of the problem. Kind regards Bernd Am 30.07.2021 um 17:45 schrieb Radoslaw Skorupka: W dniu 30.07.2021 o 17:33, Paul Gilmartin pisze: On Fri, 30 Jul 2021 09:54:51 -0500, Mike Schwab wrote: Try 5 pairs of conditions? INCLUDE COND=((5,4,CH,EQ,C'0205',AND,83,3,CH,EQ,C'YES'), OR,(5,4,CH,EQ,C'0205',AND,88,3,CH,EQ,C'YES'), OR,(5,4,CH,EQ,C'0205',AND,93,3,CH,EQ,C'YES'), OR,(5,4,CH,EQ,C'0205',AND,98,3,CH,EQ,C'YES'), OR,(5,4,CH,EQ,C'0102',AND,28,7,CH,NE,C'USE ')) What's DFSORT's operator precedence? Was it necessary to bracket the conjunctions in order that they have higher precedence than the alternations? Are you just rewriting Radoslaw's expression according to the Distributive Law? Does DFSORTT not recognize the Distributive Law? 1. Operator precedence. According to documentation AND is first. However parenthesis should change it and it is allow to use as many parenthesis as needed. 2. DFSORT should recognize the law (Rozdzielność działań in Polish) 3. I found another mystery, which seems to be APARable: The following statement gives several test records as expected: INCLUDE COND=(5,4,CH,EQ,C'0205',AND,(83,3,CH,EQ,C'YES',OR, 88,3,CH,EQ,C'YES',OR, 93,3,CH,EQ,C'YES',OR, 98,3,CH,EQ,C'YES')) But this statement gives zero records. Note, I added "OR" conditions, so it cannot narrow the output. INCLUDE COND=(5,4,CH,EQ,C'0205',AND,(83,3,CH,EQ,C'YES',OR, 88,3,CH,EQ,C'YES',OR, 93,3,CH,EQ,C'YES',OR, 99,3,CH,EQ,C'YES',OR, 103,3,CH,EQ,C'YES',OR, 113,3,CH,EQ,C'YES')) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
