Re: Can ISRDDN show the complete minor name of an ENQ'd resource?
Is there a way *YOU* (as an application programmer) can do it Of course I can, if I have to. The ISGQUERY macro provides all the info I need. My point was that the precise tool that I need is already available in ISRDDN, but unfortunately, the piece of the rname that I need to see is just beyond the end of the display, and the display isn't scrollable. I was wondering if anyone knows of another utility that would do the job. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Can ISRDDN show the complete minor name of an ENQ'd resource?
At the side of the dsn type the command ISRDDN E It's not a dataset that has the enqueue. It's an application program (CA's PanAPT) that has done an ENQ on a resource with an 84-byte minor name, and I need to see the entire rname to know who has the enqueue. I've coded my way out of this by using the ISGQUERY macro. Thanks, everyone. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Can ISRDDN show the complete minor name of an ENQ'd resource?
Anyone, I'm an application programmer. We are on z/OS 1.7. If I wish to see the system ENQ status of all ENQs for a given major name, I do this within ISRDDN, option ENQ. I filter on the major name prefix, and I see all the ENQs; voila. However, if the *entire* minor name doesn't fit on the screen, it seems that ISRDDN doesn't permit scrolling to show the remainder of the minor name. I'm told that there are other resources that can show ENQs which are in contention, but the resources I'm trying to see are not in contention. I can't seem to find a way to simply view view any/all existing ENQs that show the complete minor names. Is there a way I can do this? Thanks so much! David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Simple newbie file tailoring question
Anyone, I'm working with a skeleton that generates an EXEC statement that looks like this: //STEP1 EXEC PGM=MYPROG,REGION=4M,PARM='ZUSER' I wish to pass the value in ZUSER to MYPROG, but I see that if the TSO userid is 8 characters long, the trailing blanks from the ZUSER variable are truncated, and are not being passed to my assembler application. I.e., if the userid is USER1, I get a 5-byte parm string instead of an 8-byte parm string padded with blanks (or nulls, or anything). Is there a way to prevent the truncation, so that my application always receives a full eight-byte value, preferably blank-padded? Thank you! David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Simple newbie file tailoring question
If you are z/OS 1.8 or later Naturally, we are at z/OS 1.7. This is the sort of thing I was looking for, however. For the time being, I'll just accept the truncated PARM= and deal with it in the application (as per Bill Wilkie's earlier post). Thanks, gentlemen. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Simple newbie file tailoring question
If you have other parms at fixed offsets, then this won't work. I don't have other parms right now, but I would like to reserve the right to do so going forward. That's why I was hoping to force the length of the PARM string to 8. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
My apologies if this has already been answered but I haven't seen it. No apologies necessary! The entry that was filling up was actually not MYFILE; that entry remained at 20 bytes. The ever-growing entry seemed to contain all of the history of the concatenated DDs. With each new allocation and concatenation, it grew larger. After reading all of these very informative replies, I think that the best course of action for me will be to modify the application to process one file at a time. It may not be perfect, but it will work, and it will be scalable. Thanks so much! David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
TIOT filling up: too many dynamic concatenations
Anyone, I have a mainframe assembler application which is invoking Unix system services to get the names of all of the files in an NFS-mounted folder. The application dynamically allocates and logically concatenates these files into one giant dataset, then uses QSAM macros to read it. The DYNALLOC calls work this way: first, I dynamically allocate the first file in the folder with DDNAME MYFILE. Then the program enters a loop, performing these steps for each remaining file in the folder: 1) Dynamically allocate the file, asking the system to provide the DDNAME (I observe that these are getting the ddnames SYS1, SYS2, etc). 2) Dynamically concatenate MYFILE with the SYSx dataset just allocated (with the permanently allocated attribute on). This works beautifully; when I exit the loop, I can OPEN and GET all the records successfully from MYFILE. The problem is that I have reached a practical limit of approximately 540 files in the folder, because when I reach that point, I get a dynamic concatenation ABEND due to the TIOT filling up. I am told that our TIOT size is the default of 32K, which would allow for a maximum of 1,635 DDs in a job step. It would seem, however, that something in my allocation/concatenation loop is preventing me from reaching that number of files. There are only a handful of other DDs allocated to the step (e.g., STEPLIB, etc). If I were able to handle up to 750 (or perhaps 1,000) files at a time, it would be of immense help. At the moment, our only option seems to be to split up the files into multiple folders of 500 files each. Do I have any other options? Thanks so much. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
Ed, Field S99ERROR (after the dynamic concatenation request to DYNALLOC) is coming back with a value of X'0238': Space unavailable in task input output table (TIOT). The manual says that the application should Reduce the total number of allocated DDs and devices. Deallocate data sets that are not needed simultaneously. The only way I've found to reduce the total number of allocated DDs is to reduce the number of files in the folder. I can't deallocate any of the component allocations once they've been concatenated. I did use IDF to step through and watch the TIOT grow. With each new concatenation call, there is an entry which keeps growing in size until the TIOT fills up. I think that what I need to know is if I'm missing some approach/technique that can get around what is probably a legitimate limitation. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
Yes, it is a bit more difficult to program, but it is infinitely scalable. Of course, you are correct. I took this approach because I have inherited a pre-existing application that used to read a single mainframe dataset. It's only recently that the capability to read multiple files via NFS was made necessary. My approach worked very nicely until very recently. If I have to modify the application to work the way you've suggested, then of course, I will. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
Try putting DYNAMNBR=1024 on your EXEC card. Just tried it; no good. Same result as before. Thanks, though. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
You didn't say what language you are writing in. Mainframe assembler. Your suggestion would work, but then I would have to get into an argument with the network guys when I tell them that I need twice as much disk just so that I can do a physical concatenation of all of the files. I don't think I have a leg to stand on, given that there is a programmatic, scalable solution (i.e., processing each file on its own). I think that I might have to modify the appllication... David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Can I know programmatically if a load module has been zapped?
You can browse the load module and see IDRDATA if you know what to look for I think I might start with that approach. I have the documentation. Thanks so much, everyone, for all of your rapid and informative responses! David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Can I know programmatically if a load module has been zapped?
Anyone, Might there be a way, from within an assembler module, to know whether or not a given load module has been modified via SPZAP? I'm perfectly happy to LOAD the load module, if that's any help. I know that AMBLIST can tell me if something has been zapped, but that didn't seem like an easy interface to use from within an assembler module. Thanks so much! David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Can I know programmatically if a load module has been zapped?
it's possible to zap a module and not leave footprints, though it's not the default. Yikes! Our programmers occasionally ZAP a load module in a test load library, which is fine. When the time comes to promote the load module into a production load library, however, I would like our change management package to prevent the promotion of any load module which has been zapped. I'm prepared to do that check programmatically via an exit, if I have a reasonable way of doing it. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Newbie RACROUTE question: how to *test* authorization?
If the user has given you a data set name and asked you to operate on it, and he does not have the proper authority, then it is most appropriate to have the violation occur. Not in this case, IMO. The violations are occurring as a result of a text string scan across all members of a production source code library in CA's Panvalet format. The library contains hundreds of members, but a handful of them have UACC=NONE. Here's how: Panvalet supports *member-level* security. We create RACF pseudo-profiles that contain the member name as the last qualifier, and if we wish to read-protect a member, we set that profile to have UACC=NONE. A Panvalet security exit constructs the pseudo-profile name, and invokes RACROUTE to see if read access to the member is permitted or not. Under normal circumstances, if the security exit detects a violation of any kind, we want to know about it. But if a programmer issues a text scan of the entire library, he/she typically has no need or intention of scanning the handful of read-protected members. He's just looking for all occurrences of a variable name in the source code library (for example). The problem is that there's no easy way to instruct the scanning program to skip the read- protected members. So the programmer gets a meaningless violation for each read-protected member in the library. In my view, this ought to be an acceptable use of LOG=NONE. If the programmer isn't allowed to view the member, the security exit won't let it be scanned. The members are secure. Why record endless violations that are essentially noise, and might mask an actual hacking attempt? David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Newbie RACROUTE question: how to *test* authorization?
For your own userid, you can use LISTDSD or RLIST to check resource authorization without cutting audit records. That would be perfect... is LISTDSD something I can do from within an assembler program? Or is there an assembler macro equivalent? All I really need to do is, from within an assembler application, invoke some function that will tell me whether or not the current userid is authorized via a given RACF profile to *read* a resource. The userid will always be either the person who is logged onto TSO or is the submitter of a batch job. It will never be anyone else. I guess I should have said that up front... sorry... David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Newbie RACROUTE question: how to *test* authorization?
All I really need to do is, from within an assembler application, invoke some function that will tell me whether or not the current userid is authorized via a given RACF profile to *read* a resource. The userid will always be either the person who is logged onto TSO or is the submitter of a batch job. It will never be anyone else. And of course (as I indicated in my original post), I need to be able to do this without producing a RACF violation if the user is not authorized to read the resource. I'll shut up now... David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Newbie RACROUTE question: how to *test* authorization?
Anyone, I'm just getting familiar with the RACROUTE macro. I have a working example of the macro with REQUEST=AUTH that generates a violation when appropriate. My question is: is there a way to interrogate RACF (presumably via the RACROUTE macro) to simply *ask* whether or not a particular user has read or write access to a dataset, but without actually issuing a violation if the user is unauthorized? All I want to do is get a yea or nay answer (via R15, I assume), then proceed accordingly and programmatically. I hope this makes sense... thank you! David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Newbie RACROUTE question: how to *test* authorization?
Another way is to issue a RACROUTE REQUEST=EXTRACT LOG=NONE Am I correct when I say that both of these solutions require APF-authorization (or similar)? Might there be a way that would not require this? I wouldn't have thought that there would be a security issue with merely interrogating an authorization level, but perhaps I'm wrong... David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Are comments possible in IEBUPDTE SYSIN?
the closest you'll come to that is to put a flower box (why tombstone?) as comments preceding the SYSIN (using //* comments), or adding a dummy member Ah, so. Got it. Thanks so much for your help! David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Are comments possible in IEBUPDTE SYSIN?
Anyone, I'm a newbie with IEBUPDTE, which I'm using to add members to a temporary PDS for use in a later job step. I checked the manual, but I can't seem to find a way to add comments/remarks to the IEBUPDTE SYSIN input. Is there a way to do that? Thanks so much. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Are comments possible in IEBUPDTE SYSIN?
Utility control cards adhere to the JCL/Assembler standard allowing comments on the control cards after the last operand, and with one or more separating spaces. If that's not enough room, you're out of luck. If you're updating to a temporary, why not include comments in the contents, appropriate to the language or other format you're updating? What I've created is a SYSIN dataset to IEBUPDTE which generates the individual SYSIN members for an ICETOOL job. I.e., one generated member contains the DFSORT SYMNAMES definitions, one member is contains the TOOLIN control cards, the other members are the individual control card members for the various statements in TOOLIN. I did it this way so that I can maintain all of the control cards for the entire ICETOOL job in a single dataset, rather than in separate members. The job begins by using IEBUPDTE to burst the dataset into temporary members, which are then referenced in the ICETOOL step. I was hoping that there would be a supported IEBUPDTE syntax to have an entire line devoted to a comment, rather than my being restricted to remarks appended to the ends of control statements. That way, I could put a tombstone at the top of the IEBUPDTE input dataset explaining what the ICETOOL job does. I hope this makes sense... David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DFSORT SYMNAMES: soft lengths possible?
Anyone, I have a DFSORT question regarding symbol definitions in SYMNAMES. I did check the manual, and I don't think that what I want to do is possible, but here goes... I have the following symbol defined in a sort record: LAST_NAME,1,20,CH I'm using that symbol to BUILD that field into two different sort record formats (A and B). The field appears in different columns in records A and B. So I have these symbols defined: A_LAST_NAME,*,20,CH and B_LAST_NAME,*,20,CH I can't use the equals sign to denote use the previous length within records A and B. What I'm wondering is if there's a way I can assign a length to a symbol (for example), and then use that symbol as a constant length throughout SYMNAMES. I actually did try that, but it failed. It appears that I have no choice but to replicate the constant length of 20 for every occurrence of the last name (assuming that I never want it truncated) in every record that it appears. Am I missing something? Thanks so much. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Dynamic load module name extraction?
Anyone, Is there a way for an executing assembler program to extract its own load module name for programmatic examination? (If it matters, it would be the original load module called via an EXEC statement in the JCL; it wouldn't have been loaded by a previously executing program.) Thanks so much, David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dynamic load module name extraction?
Thanks, everyone. Someone e-mailed me with a beautiful solution. I coded this: L RF,PSATOLD-PSA(,0) L RF,TCBJSTCB-TCB(,RF) L RF,TCBJPQ-TCB(,RF) MVC NAME,CDNAME-CDENTRY(RF) and it seems to work. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CLIST question (the ampersands are killing me)
Anyone, I have inherited responsibility for a CLIST; this is not my forte. I'm trying to do something pertaining to the ampersand character, and despite my efforts, I cannot figure this out. As God is my witness, this is not a homework assignment (I'm a BAL programmer, not a sysprog). I've carved out and simplified the relevant portion of the CLIST for perusal: WRITENR === READ L DO K=1 TO LENGTH(L) IF SUBSTR(K,L)=A THEN SET X=X OPTA ELSE IF SUBSTR(K,L)=B THEN SET X=X OPTB ELSE IF SUBSTR(K,L)=C THEN SET X=X OPTC END WRITE X The CLIST above works, and the concept is simple. The user is prompted to enter a string of characters chosen from the letters A, B, and C, each of which is associated with the string OPTA, OPTB, and OPTC (respectively). The CLIST sets X to the concatenation of these strings, delimited by blanks. So if the user enters BA, X is set to OPTB OPTA (quotes added for illustration only). If the user enters CCB, X is set to OPTC OPTC OPTB. Not hard. The problem: I want each of the tokens in the generated string to be preceded by a double-ampersand. E.g., if the user enters ACB, I want X to be set to amp;OPTA amp;OPTC amp;OPTB. I have read the manuals, I have tried everything I can think of... but the ampersands have laid me low. Any help would be greatly appreciated. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CLIST question (the ampersands are killing me)
Follow up to my original post: the ampersands seem to have nailed me even in my previous message. To clarify (I hope this shows up correctly): if the user enters ABC the CLIST should produce amp;OPTA amp;OPTB amp;OPTC I.e., two ampersand characters concatenated to the relevant string (e.g., OPTA), followed by a blank, then the same thing repeated for the next input character, etc. I'm sorry for any confusion! David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CLIST question (the ampersands are killing me)
So, as you want 2 ampersands you need to use 4, and thus I suggest trying: IF SUBSTR(K,L)=A THEN SET X=STR(X) amp;amp;OPTA ELSE IF SUBSTR(K,L)=B THEN SET X=STR(amp;X) amp;amp;OPTB ELSE IF SUBSTR(K,L)=C THEN SET X=STR(amp;X) amp;amp;OPTC I've tried things like that; it is absolutely not that simple. I just tried this solution; it sets X to a single ampersand concatenated only to the last expression. For example, if the user enters ABC, the result is OPTC. There's something more to it than just doubling the ampersands. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CLIST question (the ampersands are killing me)
NRSTR did the trick! Thank you so much, everyone!!! David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CLIST question (the ampersands are killing me)
I doubt it; in fact, I doubt that you're old enough to have ever seen BAL. And you're certainly not using it on z/OS. I appreciate the CLIST information you provided in your post, but I don't understand why you have accused me of being a liar when I came here for help. This is the first time I've posted to IBM-MAIN, but it surely won't be the last. I guess I could have e-mailed John Ehrman at IBM directly to get the answer, but that didn't seem appropriate. He has helped me enough with BAL-related issues, and CLIST isn't BAL. I am a 46-year-old, 23-year veteran BAL programmer, on z/OS. I've seen many of your posts, and have no reason to doubt anything you say. Any particular reason that you've accused me of being a liar on a public listserv without knowing anything about me? David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CLIST question (the ampersands are killing me)
I think he was picking on BAL because in some contexts that refers to an old Assembler and is therefore not accurate for our context. Right... someone else said the same thing. So I'm a HLASM programmer. But for the record, whatever language it is, I learned it originally in 1980 from the Struble text (it might have been the first edition). Was that BAL? I doubt it was HLASM... David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CLIST question (the ampersands are killing me)
We all know what you mean, David, but a few of us tend to prefer the terms that are technically correct. I see that! Mea maxima culpa. I'll be more careful next time... David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
