Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
> EXECIO in REXX will give you the record count in stem zero I believe only by reading the entire file. On Fri, May 15, 2020 at 8:02 AM Charles Mills wrote: > > EXECIO in REXX will give you the record count in stem zero > > I believe only by reading the entire file. > > Charles > Agree Charles. It's sort of hidden and would need a large memory allocation for the stem. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Wayne Bickerdike > Sent: Thursday, May 14, 2020 2:31 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > EXECIO in REXX will give you the record count in stem zero. For FB you > obtain LRECL using LENGTH function. Multiply the two. No good for VB, so > that would require reading whole file. > > > > > On Fri, May 15, 2020, 07:05 Gerhard adam wrote: > > > > > > > > > > > Really? There’s lots that it could do? So why not just read the > > DSCB for how much is free and do the calculation that has been on every > > 3390 Reference card for 30 years > > This is done all the time and in a variety of ways. This problem was > > readily assessed for decades using a subroutine. This has always been > > something that could readily be done until people start putting language > > restrictions on it. It isn’t that the info isn’t available, it is simply > > that the information isn’t available given the restrictions placed on the > > problem > > > > > > > > Get Outlook for iOS > > > > > > > > > > > > > > On Thu, May 14, 2020 at 1:56 PM -0700, "Charles Mills" > > > wrote: > > > > > > > > > > > > > > > > > > > > > > There is lots it could do! Make a decision on "strategy" based on the > > volume of input, for example. Do I process it all or cut off after 'n' > > records and do more on the next run? Do I read the file into an in-memory > > table and access records there, or do I load it into a VSAM file for > direct > > access? Do I invoke an external sort or use an internal sort? Or a > thousand > > other things. > > > > It is wrong as @Shmuel points out to preclude questioning the necessity > of > > doing something exactly as the OP suggests. It is equally wrong to assume > > there could be no good reason for doing it the OP's way. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Gerhard adam > > Sent: Thursday, May 14, 2020 11:52 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > > non-zFS, non-database files? > > > > > > > > > > > > It is easy to say that a COBOL program needs to “know” this but > it > > is nonsense since there is nothing a COBOL program can do with this info. > > If it turns out to really be necessary then a subroutine can be written > > (as it has been done for decades) to provide this information. > > If the question is simply to bitch about why z/OS does do this > > automatically via a call or something then the complaint is directed to > the > > wrong group > > > > -- > > 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS: su: User ID "SH" does not exist
On 5/14/2020 5:23 PM, Jon Bathmaker wrote: //STDPARM DD * SH su SH echo $PATH SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS The above looks wrong to me. I always do it this way: //STDPARM DD * SH su; echo $PATH; unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS: su: User ID "SH" does not exist
On Thu, 14 May 2020 22:21:27 -0400, Tom Conley wrote: > >Try setting up sudo to do the command all at once. "sudo unmount.". >Using su requires a password that you would not want in the clear. > That setup might be in /etc/sudoers or in a RACF BPX.SUPERUSER privilege class. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxb200/sprclass.htm -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS: su: User ID "SH" does not exist
On 5/14/2020 8:23 PM, Jon Bathmaker wrote: Hi, Because of auditor demands we are no longer able to run TSO USS commands that require UID=0, so I attempting figure out how to run USS commands in under BPXBATCH. The following is a job to debug the unmount command in batch but I have been unsuccessful so far. I am hoping that I am doing something wrong and that one of you can point out my error. Here is the JCL: //BATBPX EXEC PGM=BPXBATCH //STEPLIB DD DISP=SHR,DSN=SYS1.CEE.SCEERUN //STDERR DD SYSOUT=* //STDOUT DD SYSOUT=* //STDPARM DD * SH su SH echo $PATH SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS Here is the contents of STDERR when the job runs. FSUM5023 su: User ID "SH" does not exist, or the RACF profile does not contain an OMVS segment. Thanks. Best regards, Jon Bathmaker z/OS Systems Programmer Hey John, Try setting up sudo to do the command all at once. "sudo unmount.". Using su requires a password that you would not want in the clear. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
The OP didn't ask for a size in tracks and didn't ask for an approximation. All of this is guesswork unless and until he knows more and is allowed to tell us. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mike Schwab [mike.a.sch...@gmail.com] Sent: Thursday, May 14, 2020 9:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? IDCAMS command DCOLLECT for the dataset name into a file then read the file. Divide by about 55k to get the number of tracks used. Assume all tracks are full and the partial track would be the error amount. On Thu, May 14, 2020 at 4:27 PM Lizette Koehler wrote: > > Maybe the Catalog Search Function (CSI) might be able to help. > > See it that could be something usable > > Lizette > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Seymour J Metz > Sent: Thursday, May 14, 2020 9:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > No, and I'm not even sure what the question means. If what you want is the > sum of the record lengths then you have to read through the entire file and > add up the lengths. If you want to know how big it will look to a Unix > application hen you'll need to add the number of records to account for the > LF or NL characters, unless the application is reading it as binary. The one > exception is that if it is a valid FBS dataset then you can calculate the > size. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of > Farley, Peter x23353 > Sent: Thursday, May 14, 2020 11:55 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, > non-database files? > > This question came to me from a co-worker: Is there any API to get the byte > file size of a non-VSAM, non-zFS, non-database file in z/OS? I.E., byte > file size for plain sequential files? > > I am aware of the "old way" of reading the VTOC of a volume to get the > various DSCB's that total up disk extents, but that gets complicated quickly > for multi-volume files, and was never guaranteed to be accurate as to the > actual byte count of data in the file except in the RECFM=FS/FBS case > anyway. > > There is always the performance-killing option of just reading the whole > file and totaling up the length of every record (or block depending on how > you structure the reads), but no one would call that an API. > > As far as I know there is no such API in z/OS, and this is what I told my > co-worker, but am I wrong? Is there an alternative of which I am not aware? > > TIA for your input. > > Peter > -- > > > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > -- > 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
IDCAMS command DCOLLECT for the dataset name into a file then read the file. Divide by about 55k to get the number of tracks used. Assume all tracks are full and the partial track would be the error amount. On Thu, May 14, 2020 at 4:27 PM Lizette Koehler wrote: > > Maybe the Catalog Search Function (CSI) might be able to help. > > See it that could be something usable > > Lizette > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Seymour J Metz > Sent: Thursday, May 14, 2020 9:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > No, and I'm not even sure what the question means. If what you want is the > sum of the record lengths then you have to read through the entire file and > add up the lengths. If you want to know how big it will look to a Unix > application hen you'll need to add the number of records to account for the > LF or NL characters, unless the application is reading it as binary. The one > exception is that if it is a valid FBS dataset then you can calculate the > size. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of > Farley, Peter x23353 > Sent: Thursday, May 14, 2020 11:55 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, > non-database files? > > This question came to me from a co-worker: Is there any API to get the byte > file size of a non-VSAM, non-zFS, non-database file in z/OS? I.E., byte > file size for plain sequential files? > > I am aware of the "old way" of reading the VTOC of a volume to get the > various DSCB's that total up disk extents, but that gets complicated quickly > for multi-volume files, and was never guaranteed to be accurate as to the > actual byte count of data in the file except in the RECFM=FS/FBS case > anyway. > > There is always the performance-killing option of just reading the whole > file and totaling up the length of every record (or block depending on how > you structure the reads), but no one would call that an API. > > As far as I know there is no such API in z/OS, and this is what I told my > co-worker, but am I wrong? Is there an alternative of which I am not aware? > > TIA for your input. > > Peter > -- > > > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > -- > 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 -- 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: USS Open in SYSCALL ENV
On Thu, 14 May 2020 18:11:12 +, Seymour J Metz wrote: >There's cleverness and there's glitz; they're not the same modern e-mail >clients have lots of glitz and very little cleverness. A clever client makes >it easy to do what you need to do, doesn't automatically do things that you >shouldn't be doing and gives unobtrusive feedback when you do something >questionable. > >And, yes, exact quotes are much more useful than paraphrases when you're >trying to shoot a problem. > And far better than the glitzy quotation marks that some MUAs insist on supplying. >For REXX issues I always like to see the results with trace i active and for >HLASM I like to see both the source and the relevant lines from the listing; >sometimes the latter isn't what I expect it to be, and that can help pinpoint >the problem. > >But I'm preaching to the quire. > quire: noun four sheets of paper or parchment folded to form eight leaves, as in medieval manuscripts. Soundex strikes again. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS: su: User ID "SH" does not exist
On Thu, 14 May 2020 20:23:20 -0400, Jon Bathmaker wrote: > > >//STDERR�� DD SYSOUT=* > >//STDOUT� �DD SYSOUT=* > >//STDPARM� DD * > >SH su > >SH echo $PATH > >SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS > >Here is the contents of STDERR when the job runs. > >FSUM5023 su: User ID "SH" does not exist, or the RACF profile does not >contain an OMVS segment. > Why do your auditors prohibit UID 0 from TSO but allow it otherwise? I'll recommend BPXWUNIX as a superior alternative. And SYSIN for bpxwunix can then be an instream data set. I haven't the stamina to compose all the RCFs the description of STDPARM in the Command Ref. deserves. A couple examples: If a MVS data set is specified: • Specify one argument per line. What's an "argument" Should PGM or SH be specified on only the first line, or on every line? If the latter, is a mixture of PGM and SH supported? • Trailing blanks are truncated for SYSIN and variable block data sets, but not for fixed block data sets. For a fixed block data set, trailing blanks will be included in the parameter text for a given argument up to the end of the record. WTF!? It makes sense to truncate for fixed, where the programmer can't control trailing blanks. For variable, the programmer has control and trailing blanks should be preserved. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS: su: User ID "SH" does not exist
Who is "we", exactly what were the auditors' demands and did you discuss the issues with your management? What you have in stdparm is not a long parameter but a sequence of parameters. Is that legal, or will BPXBATCH take all of the input after the initial sh as one long command? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jon Bathmaker Sent: Thursday, May 14, 2020 8:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: USS: su: User ID "SH" does not exist Hi, Because of auditor demands we are no longer able to run TSO USS commands that require UID=0, so I attempting figure out how to run USS commands in under BPXBATCH. The following is a job to debug the unmount command in batch but I have been unsuccessful so far. I am hoping that I am doing something wrong and that one of you can point out my error. Here is the JCL: //BATBPX EXEC PGM=BPXBATCH //STEPLIB DD DISP=SHR,DSN=SYS1.CEE.SCEERUN //STDERR DD SYSOUT=* //STDOUT DD SYSOUT=* //STDPARM DD * SH su SH echo $PATH SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS Here is the contents of STDERR when the job runs. FSUM5023 su: User ID "SH" does not exist, or the RACF profile does not contain an OMVS segment. Thanks. Best regards, Jon Bathmaker z/OS Systems Programmer -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
I've got it now. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Farley, Peter x23353 [peter.far...@broadridge.com] Sent: Thursday, May 14, 2020 6:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Shmuel, Did you miss my answer? I got it sent back to me from the list at 4:41PM EDT. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 14, 2020 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Again, you're giving the right answer to the wrong question. The OP did not ask how many tracks were allocated, he asked for the file size in bytes. Since the OP hasn't told us why he wants the information, it is presumptuous to presume that he should shut up and use something different from what he asked for. Several people have asked him to clarify that point, but he hasn't chosen to do so. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Gerhard adam [gada...@charter.net] Sent: Thursday, May 14, 2020 5:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Really? There's lots that it could do? So why not just read the DSCB for how much is free and do the calculation that has been on every 3390 Reference card for 30 years This is done all the time and in a variety of ways. This problem was readily assessed for decades using a subroutine. This has always been something that could readily be done until people start putting language restrictions on it. It isn't that the info isn't available, it is simply that the information isn't available given the restrictions placed on the problem On Thu, May 14, 2020 at 1:56 PM -0700, "Charles Mills" wrote: There is lots it could do! Make a decision on "strategy" based on the volume of input, for example. Do I process it all or cut off after 'n' records and do more on the next run? Do I read the file into an in-memory table and access records there, or do I load it into a VSAM file for direct access? Do I invoke an external sort or use an internal sort? Or a thousand other things. It is wrong as @Shmuel points out to preclude questioning the necessity of doing something exactly as the OP suggests. It is equally wrong to assume there could be no good reason for doing it the OP's way. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Thursday, May 14, 2020 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is easy to say that a COBOL program needs to "know" this but it is nonsense since there is nothing a COBOL program can do with this info. If it turns out to really be necessary then a subroutine can be written (as it has been done for decades) to provide this information. If the question is simply to bitch about why z/OS does do this automatically via a call or something then the complaint is directed to the wrong group -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
USS: su: User ID "SH" does not exist
Hi, Because of auditor demands we are no longer able to run TSO USS commands that require UID=0, so I attempting figure out how to run USS commands in under BPXBATCH. The following is a job to debug the unmount command in batch but I have been unsuccessful so far. I am hoping that I am doing something wrong and that one of you can point out my error. Here is the JCL: //BATBPX EXEC PGM=BPXBATCH //STEPLIB DD DISP=SHR,DSN=SYS1.CEE.SCEERUN //STDERR DD SYSOUT=* //STDOUT DD SYSOUT=* //STDPARM DD * SH su SH echo $PATH SH unmount -fv ZOS240.SYS1.OMVS.SYSRES.OS240971.FNT.ZFS Here is the contents of STDERR when the job runs. FSUM5023 su: User ID "SH" does not exist, or the RACF profile does not contain an OMVS segment. Thanks. Best regards, Jon Bathmaker z/OS Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Shmuel, Did you miss my answer? I got it sent back to me from the list at 4:41PM EDT. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 14, 2020 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Again, you're giving the right answer to the wrong question. The OP did not ask how many tracks were allocated, he asked for the file size in bytes. Since the OP hasn't told us why he wants the information, it is presumptuous to presume that he should shut up and use something different from what he asked for. Several people have asked him to clarify that point, but he hasn't chosen to do so. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Gerhard adam [gada...@charter.net] Sent: Thursday, May 14, 2020 5:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Really? There's lots that it could do? So why not just read the DSCB for how much is free and do the calculation that has been on every 3390 Reference card for 30 years This is done all the time and in a variety of ways. This problem was readily assessed for decades using a subroutine. This has always been something that could readily be done until people start putting language restrictions on it. It isn't that the info isn't available, it is simply that the information isn't available given the restrictions placed on the problem On Thu, May 14, 2020 at 1:56 PM -0700, "Charles Mills" wrote: There is lots it could do! Make a decision on "strategy" based on the volume of input, for example. Do I process it all or cut off after 'n' records and do more on the next run? Do I read the file into an in-memory table and access records there, or do I load it into a VSAM file for direct access? Do I invoke an external sort or use an internal sort? Or a thousand other things. It is wrong as @Shmuel points out to preclude questioning the necessity of doing something exactly as the OP suggests. It is equally wrong to assume there could be no good reason for doing it the OP's way. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Thursday, May 14, 2020 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is easy to say that a COBOL program needs to "know" this but it is nonsense since there is nothing a COBOL program can do with this info. If it turns out to really be necessary then a subroutine can be written (as it has been done for decades) to provide this information. If the question is simply to bitch about why z/OS does do this automatically via a call or something then the complaint is directed to the wrong group -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Well then, that is a good answer to his question, so why don't you suggest that? (Actually, you have.) The fact that there is a good answer does not make it a bad question. (Good answer subject to some limitations that have been discussed.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Thursday, May 14, 2020 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Really? There’s lots that it could do? So why not just read the DSCB for how much is free and do the calculation that has been on every 3390 Reference card for 30 years This is done all the time and in a variety of ways. This problem was readily assessed for decades using a subroutine. This has always been something that could readily be done until people start putting language restrictions on it. It isn’t that the info isn’t available, it is simply that the information isn’t available given the restrictions placed on the problem -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
> EXECIO in REXX will give you the record count in stem zero I believe only by reading the entire file. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 14, 2020 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? EXECIO in REXX will give you the record count in stem zero. For FB you obtain LRECL using LENGTH function. Multiply the two. No good for VB, so that would require reading whole file. On Fri, May 15, 2020, 07:05 Gerhard adam wrote: > > > > > Really? There’s lots that it could do? So why not just read the > DSCB for how much is free and do the calculation that has been on every > 3390 Reference card for 30 years > This is done all the time and in a variety of ways. This problem was > readily assessed for decades using a subroutine. This has always been > something that could readily be done until people start putting language > restrictions on it. It isn’t that the info isn’t available, it is simply > that the information isn’t available given the restrictions placed on the > problem > > > > Get Outlook for iOS > > > > > > > On Thu, May 14, 2020 at 1:56 PM -0700, "Charles Mills" > wrote: > > > > > > > > > > > There is lots it could do! Make a decision on "strategy" based on the > volume of input, for example. Do I process it all or cut off after 'n' > records and do more on the next run? Do I read the file into an in-memory > table and access records there, or do I load it into a VSAM file for direct > access? Do I invoke an external sort or use an internal sort? Or a thousand > other things. > > It is wrong as @Shmuel points out to preclude questioning the necessity of > doing something exactly as the OP suggests. It is equally wrong to assume > there could be no good reason for doing it the OP's way. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gerhard adam > Sent: Thursday, May 14, 2020 11:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > > > > > It is easy to say that a COBOL program needs to “know” this but it > is nonsense since there is nothing a COBOL program can do with this info. > If it turns out to really be necessary then a subroutine can be written > (as it has been done for decades) to provide this information. > If the question is simply to bitch about why z/OS does do this > automatically via a call or something then the complaint is directed to the > wrong group > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Activate SMS configuration in batch
I'd probably use TSSO, but there are many options. The important part is to know what messages to watch for. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Doug [dsh...@bellsouth.net] Sent: Thursday, May 14, 2020 4:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Activate SMS configuration in batch Yep, REXX and CONSOLE and D SMS trap and parse for time in all LPARS. ACTIVATE new SCDS . Wait the appropriate number of seconds for all LPARS to update. D SMS trap and parse and verify all LPARS are current, if not , D SMS again. Been a long time since activation has failed . Navi quest can do the update too. It is So ISPF centric it can be problematic. My 2 cents Regards, Doug . On May 14, 2020, at 16:25, Seymour J Metz wrote: I was giving my CONDOLEnces to the CONSOLE. BTW, that wasn't the only typo. It was the keyboard. That's my story and I'm sticking to it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Spiegel [dspiegel...@hotmail.com] Sent: Thursday, May 14, 2020 3:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Activate SMS configuration in batch You said: "... you could do it with CONDOLE ..." Qu'est-ce que c'est "CONDOLE" (is he related to Bob Dole or Dole pineapple)? > On 2020-05-14 14:52, Seymour J Metz wrote: > If you just wanted to wait until the SETSMS command was comple you could do > it with CONDOLE, but AFAIK SETSMS and SET SMS= hand off the request to an SMS > address space and complete before the change is in effect. My guess is that > the only way is wait for a message from SMS. > > > -- > Shmuel (Seymour J.) Metz > https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7C65c7cf097c244c0ec69c08d7f838096d%7C84df9e7fe9f640afb435%7C1%7C0%7C637250791867491461&sdata=gQvp8jk0y9EztvvjnfbxWS7lI2OLdeGdo64esMyNLV0%3D&reserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Gadi Ben-Avi [gad...@malam.com] > Sent: Thursday, May 14, 2020 6:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Activate SMS configuration in batch > > Hi, > Does anyone know of a way to activate an SMS configuration in batch? > > I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a > way that will wait until the activation is complete before continuing to the > next step. > > We are running z/OS v2.2 > > Thanks > > Gadi > > > -- > 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 -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
EXECIO in REXX will give you the record count in stem zero. For FB you obtain LRECL using LENGTH function. Multiply the two. No good for VB, so that would require reading whole file. On Fri, May 15, 2020, 07:05 Gerhard adam wrote: > > > > > Really? There’s lots that it could do? So why not just read the > DSCB for how much is free and do the calculation that has been on every > 3390 Reference card for 30 years > This is done all the time and in a variety of ways. This problem was > readily assessed for decades using a subroutine. This has always been > something that could readily be done until people start putting language > restrictions on it. It isn’t that the info isn’t available, it is simply > that the information isn’t available given the restrictions placed on the > problem > > > > Get Outlook for iOS > > > > > > > On Thu, May 14, 2020 at 1:56 PM -0700, "Charles Mills" > wrote: > > > > > > > > > > > There is lots it could do! Make a decision on "strategy" based on the > volume of input, for example. Do I process it all or cut off after 'n' > records and do more on the next run? Do I read the file into an in-memory > table and access records there, or do I load it into a VSAM file for direct > access? Do I invoke an external sort or use an internal sort? Or a thousand > other things. > > It is wrong as @Shmuel points out to preclude questioning the necessity of > doing something exactly as the OP suggests. It is equally wrong to assume > there could be no good reason for doing it the OP's way. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gerhard adam > Sent: Thursday, May 14, 2020 11:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > > > > > It is easy to say that a COBOL program needs to “know” this but it > is nonsense since there is nothing a COBOL program can do with this info. > If it turns out to really be necessary then a subroutine can be written > (as it has been done for decades) to provide this information. > If the question is simply to bitch about why z/OS does do this > automatically via a call or something then the complaint is directed to the > wrong group > > -- > 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: Activate SMS configuration in batch
If TSSO still works, its price is attractive. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Wayne Bickerdike [wayn...@gmail.com] Sent: Thursday, May 14, 2020 5:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Activate SMS configuration in batch If a shop doesnt have automation, there are plenty of freebies that will do the job. Tom Brennans Vista can even be programmed to look for text on a screen and issue a command. REXX and ISFSLASH command issuance with a suitable time delay should suffice. On Fri, May 15, 2020, 07:00 Doug wrote: > Yep, > REXX and CONSOLE and > D SMS > trap and parse for time in all LPARS. > ACTIVATE new SCDS . > Wait the appropriate number of seconds for all LPARS to update. > D SMS > trap and parse and verify all LPARS are current, if not , D SMS again. > > Been a long time since activation has failed . > > Navi quest can do the update too. It is So ISPF centric it can be > problematic. > > My 2 cents > Regards, Doug > > > > > . > > On May 14, 2020, at 16:25, Seymour J Metz wrote: > > I was giving my CONDOLEnces to the CONSOLE. BTW, that wasn't the only > typo. > > It was the keyboard. That's my story and I'm sticking to it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of David Spiegel [dspiegel...@hotmail.com] > Sent: Thursday, May 14, 2020 3:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Activate SMS configuration in batch > > You said: "... you could do it with CONDOLE ..." > Qu'est-ce que c'est "CONDOLE" (is he related to Bob Dole or Dole > pineapple)? > > > On 2020-05-14 14:52, Seymour J Metz wrote: > > If you just wanted to wait until the SETSMS command was comple you could > do it with CONDOLE, but AFAIK SETSMS and SET SMS= hand off the request to > an SMS address space and complete before the change is in effect. My guess > is that the only way is wait for a message from SMS. > > > > > > -- > > Shmuel (Seymour J.) Metz > > > https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7C65c7cf097c244c0ec69c08d7f838096d%7C84df9e7fe9f640afb435%7C1%7C0%7C637250791867491461&sdata=gQvp8jk0y9EztvvjnfbxWS7lI2OLdeGdo64esMyNLV0%3D&reserved=0 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Gadi Ben-Avi [gad...@malam.com] > > Sent: Thursday, May 14, 2020 6:43 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Activate SMS configuration in batch > > > > Hi, > > Does anyone know of a way to activate an SMS configuration in batch? > > > > I know I can issue the SETSMS SCDS(xx) command in batch, but I am long > for a way that will wait until the activation is complete before continuing > to the next step. > > > > We are running z/OS v2.2 > > > > Thanks > > > > Gadi > > > > > > -- > > 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 > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Again, you're giving the right answer to the wrong question. The OP did not ask how many tracks were allocated, he asked for the file size in bytes. Since the OP hasn't told us why he wants the information, it is presumptuous to presume that he should shut up and use something different from what he asked for. Several people have asked him to clarify that point, but he hasn't chosen to do so. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Gerhard adam [gada...@charter.net] Sent: Thursday, May 14, 2020 5:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Really? There’s lots that it could do? So why not just read the DSCB for how much is free and do the calculation that has been on every 3390 Reference card for 30 years This is done all the time and in a variety of ways. This problem was readily assessed for decades using a subroutine. This has always been something that could readily be done until people start putting language restrictions on it. It isn’t that the info isn’t available, it is simply that the information isn’t available given the restrictions placed on the problem Get Outlook for iOS On Thu, May 14, 2020 at 1:56 PM -0700, "Charles Mills" wrote: There is lots it could do! Make a decision on "strategy" based on the volume of input, for example. Do I process it all or cut off after 'n' records and do more on the next run? Do I read the file into an in-memory table and access records there, or do I load it into a VSAM file for direct access? Do I invoke an external sort or use an internal sort? Or a thousand other things. It is wrong as @Shmuel points out to preclude questioning the necessity of doing something exactly as the OP suggests. It is equally wrong to assume there could be no good reason for doing it the OP's way. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Thursday, May 14, 2020 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is easy to say that a COBOL program needs to “know” this but it is nonsense since there is nothing a COBOL program can do with this info. If it turns out to really be necessary then a subroutine can be written (as it has been done for decades) to provide this information. If the question is simply to bitch about why z/OS does do this automatically via a call or something then the complaint is directed to the wrong group -- 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: Activate SMS configuration in batch
Oh geez, CONSOLE and it must be getting really close to Friday too. Pineapple . On May 14, 2020, at 15:39, David Spiegel wrote: You said: "... you could do it with CONDOLE ..." Qu'est-ce que c'est "CONDOLE" (is he related to Bob Dole or Dole pineapple)? > On 2020-05-14 14:52, Seymour J Metz wrote: > If you just wanted to wait until the SETSMS command was comple you could do > it with CONDOLE, but AFAIK SETSMS and SET SMS= hand off the request to an SMS > address space and complete before the change is in effect. My guess is that > the only way is wait for a message from SMS. > > > -- > Shmuel (Seymour J.) Metz > https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7C65c7cf097c244c0ec69c08d7f838096d%7C84df9e7fe9f640afb435%7C1%7C0%7C637250791867491461&sdata=gQvp8jk0y9EztvvjnfbxWS7lI2OLdeGdo64esMyNLV0%3D&reserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Gadi Ben-Avi [gad...@malam.com] > Sent: Thursday, May 14, 2020 6:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Activate SMS configuration in batch > > Hi, > Does anyone know of a way to activate an SMS configuration in batch? > > I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a > way that will wait until the activation is complete before continuing to the > next step. > > We are running z/OS v2.2 > > Thanks > > Gadi > > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Activate SMS configuration in batch
If a shop doesnt have automation, there are plenty of freebies that will do the job. Tom Brennans Vista can even be programmed to look for text on a screen and issue a command. REXX and ISFSLASH command issuance with a suitable time delay should suffice. On Fri, May 15, 2020, 07:00 Doug wrote: > Yep, > REXX and CONSOLE and > D SMS > trap and parse for time in all LPARS. > ACTIVATE new SCDS . > Wait the appropriate number of seconds for all LPARS to update. > D SMS > trap and parse and verify all LPARS are current, if not , D SMS again. > > Been a long time since activation has failed . > > Navi quest can do the update too. It is So ISPF centric it can be > problematic. > > My 2 cents > Regards, Doug > > > > > . > > On May 14, 2020, at 16:25, Seymour J Metz wrote: > > I was giving my CONDOLEnces to the CONSOLE. BTW, that wasn't the only > typo. > > It was the keyboard. That's my story and I'm sticking to it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of David Spiegel [dspiegel...@hotmail.com] > Sent: Thursday, May 14, 2020 3:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Activate SMS configuration in batch > > You said: "... you could do it with CONDOLE ..." > Qu'est-ce que c'est "CONDOLE" (is he related to Bob Dole or Dole > pineapple)? > > > On 2020-05-14 14:52, Seymour J Metz wrote: > > If you just wanted to wait until the SETSMS command was comple you could > do it with CONDOLE, but AFAIK SETSMS and SET SMS= hand off the request to > an SMS address space and complete before the change is in effect. My guess > is that the only way is wait for a message from SMS. > > > > > > -- > > Shmuel (Seymour J.) Metz > > > https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7C65c7cf097c244c0ec69c08d7f838096d%7C84df9e7fe9f640afb435%7C1%7C0%7C637250791867491461&sdata=gQvp8jk0y9EztvvjnfbxWS7lI2OLdeGdo64esMyNLV0%3D&reserved=0 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Gadi Ben-Avi [gad...@malam.com] > > Sent: Thursday, May 14, 2020 6:43 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Activate SMS configuration in batch > > > > Hi, > > Does anyone know of a way to activate an SMS configuration in batch? > > > > I know I can issue the SETSMS SCDS(xx) command in batch, but I am long > for a way that will wait until the activation is complete before continuing > to the next step. > > > > We are running z/OS v2.2 > > > > Thanks > > > > Gadi > > > > > > -- > > 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 > > -- > 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Really? There’s lots that it could do? So why not just read the DSCB for how much is free and do the calculation that has been on every 3390 Reference card for 30 years This is done all the time and in a variety of ways. This problem was readily assessed for decades using a subroutine. This has always been something that could readily be done until people start putting language restrictions on it. It isn’t that the info isn’t available, it is simply that the information isn’t available given the restrictions placed on the problem Get Outlook for iOS On Thu, May 14, 2020 at 1:56 PM -0700, "Charles Mills" wrote: There is lots it could do! Make a decision on "strategy" based on the volume of input, for example. Do I process it all or cut off after 'n' records and do more on the next run? Do I read the file into an in-memory table and access records there, or do I load it into a VSAM file for direct access? Do I invoke an external sort or use an internal sort? Or a thousand other things. It is wrong as @Shmuel points out to preclude questioning the necessity of doing something exactly as the OP suggests. It is equally wrong to assume there could be no good reason for doing it the OP's way. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Thursday, May 14, 2020 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is easy to say that a COBOL program needs to “know” this but it is nonsense since there is nothing a COBOL program can do with this info. If it turns out to really be necessary then a subroutine can be written (as it has been done for decades) to provide this information. If the question is simply to bitch about why z/OS does do this automatically via a call or something then the complaint is directed to the wrong group -- 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: Activate SMS configuration in batch
Yep, REXX and CONSOLE and D SMS trap and parse for time in all LPARS. ACTIVATE new SCDS . Wait the appropriate number of seconds for all LPARS to update. D SMS trap and parse and verify all LPARS are current, if not , D SMS again. Been a long time since activation has failed . Navi quest can do the update too. It is So ISPF centric it can be problematic. My 2 cents Regards, Doug . On May 14, 2020, at 16:25, Seymour J Metz wrote: I was giving my CONDOLEnces to the CONSOLE. BTW, that wasn't the only typo. It was the keyboard. That's my story and I'm sticking to it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Spiegel [dspiegel...@hotmail.com] Sent: Thursday, May 14, 2020 3:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Activate SMS configuration in batch You said: "... you could do it with CONDOLE ..." Qu'est-ce que c'est "CONDOLE" (is he related to Bob Dole or Dole pineapple)? > On 2020-05-14 14:52, Seymour J Metz wrote: > If you just wanted to wait until the SETSMS command was comple you could do > it with CONDOLE, but AFAIK SETSMS and SET SMS= hand off the request to an SMS > address space and complete before the change is in effect. My guess is that > the only way is wait for a message from SMS. > > > -- > Shmuel (Seymour J.) Metz > https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7C65c7cf097c244c0ec69c08d7f838096d%7C84df9e7fe9f640afb435%7C1%7C0%7C637250791867491461&sdata=gQvp8jk0y9EztvvjnfbxWS7lI2OLdeGdo64esMyNLV0%3D&reserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Gadi Ben-Avi [gad...@malam.com] > Sent: Thursday, May 14, 2020 6:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Activate SMS configuration in batch > > Hi, > Does anyone know of a way to activate an SMS configuration in batch? > > I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a > way that will wait until the activation is complete before continuing to the > next step. > > We are running z/OS v2.2 > > Thanks > > Gadi > > > -- > 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 -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
There is lots it could do! Make a decision on "strategy" based on the volume of input, for example. Do I process it all or cut off after 'n' records and do more on the next run? Do I read the file into an in-memory table and access records there, or do I load it into a VSAM file for direct access? Do I invoke an external sort or use an internal sort? Or a thousand other things. It is wrong as @Shmuel points out to preclude questioning the necessity of doing something exactly as the OP suggests. It is equally wrong to assume there could be no good reason for doing it the OP's way. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Thursday, May 14, 2020 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is easy to say that a COBOL program needs to “know” this but it is nonsense since there is nothing a COBOL program can do with this info. If it turns out to really be necessary then a subroutine can be written (as it has been done for decades) to provide this information. If the question is simply to bitch about why z/OS does do this automatically via a call or something then the complaint is directed to the wrong group -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Gentle listers, it's not that big a deal. As to why my co-worker wants that information or what they think they need to do with it, I do not know nor did I think to ask, as it was just phrased as "can I get this information from a batch COBOL program?". And I did not have the luxury of time to delve further into the subject as I have my own urgent priorities to deal with. As to the intended use of the information, if my co-worker is permitted to share that with me I'll share it here. In the meantime, my original question is answered: There is no easily callable API (bar LISTDSI from Rexx, FSVO "easy") available to provide that information for such files, as I surmised based on my own experience and as I initially replied to my co-worker. Thank you. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Thursday, May 14, 2020 3:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? On Thu, 14 May 2020 18:52:09 +, Gerhard adam wrote: > > It is easy to say that a COBOL program needs to “know” this but it is > nonsense since there is nothing a COBOL program can do with this info. > It could print it in a report. I suspect cultural familiarity, the complement of a presentation I attended circa 1980 where IBM was selling a then-innovative online service. The presenter said the base subscription entitled the customer to one megabyte of storage. Question from the audience: "How much is that in cylinders?" Of course, it depends. 1.75 cylinders. Someone with a different background might have been familiar with 1.36 floppy disks. >If it turns out to really be necessary then a subroutine can be written >(as it has been done for decades) to provide this information. If the >question is simply to bitch about why z/OS does do this automatically >via a call or something then the complaint is directed to the wrong >group > Keep your data in zFS. Then "ls -l" gives the answer immediately. How readily can COBOL access zFS files. BPXWDYN should make it routine. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Activate SMS configuration in batch
I was giving my CONDOLEnces to the CONSOLE. BTW, that wasn't the only typo. It was the keyboard. That's my story and I'm sticking to it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Spiegel [dspiegel...@hotmail.com] Sent: Thursday, May 14, 2020 3:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Activate SMS configuration in batch You said: "... you could do it with CONDOLE ..." Qu'est-ce que c'est "CONDOLE" (is he related to Bob Dole or Dole pineapple)? On 2020-05-14 14:52, Seymour J Metz wrote: > If you just wanted to wait until the SETSMS command was comple you could do > it with CONDOLE, but AFAIK SETSMS and SET SMS= hand off the request to an SMS > address space and complete before the change is in effect. My guess is that > the only way is wait for a message from SMS. > > > -- > Shmuel (Seymour J.) Metz > https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7C65c7cf097c244c0ec69c08d7f838096d%7C84df9e7fe9f640afb435%7C1%7C0%7C637250791867491461&sdata=gQvp8jk0y9EztvvjnfbxWS7lI2OLdeGdo64esMyNLV0%3D&reserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Gadi Ben-Avi [gad...@malam.com] > Sent: Thursday, May 14, 2020 6:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Activate SMS configuration in batch > > Hi, > Does anyone know of a way to activate an SMS configuration in batch? > > I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a > way that will wait until the activation is complete before continuing to the > next step. > > We are running z/OS v2.2 > > Thanks > > Gadi > > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Activate SMS configuration in batch
You said: "... you could do it with CONDOLE ..." Qu'est-ce que c'est "CONDOLE" (is he related to Bob Dole or Dole pineapple)? On 2020-05-14 14:52, Seymour J Metz wrote: If you just wanted to wait until the SETSMS command was comple you could do it with CONDOLE, but AFAIK SETSMS and SET SMS= hand off the request to an SMS address space and complete before the change is in effect. My guess is that the only way is wait for a message from SMS. -- Shmuel (Seymour J.) Metz https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7C65c7cf097c244c0ec69c08d7f838096d%7C84df9e7fe9f640afb435%7C1%7C0%7C637250791867491461&sdata=gQvp8jk0y9EztvvjnfbxWS7lI2OLdeGdo64esMyNLV0%3D&reserved=0 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Gadi Ben-Avi [gad...@malam.com] Sent: Thursday, May 14, 2020 6:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Activate SMS configuration in batch Hi, Does anyone know of a way to activate an SMS configuration in batch? I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a way that will wait until the activation is complete before continuing to the next step. We are running z/OS v2.2 Thanks Gadi -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
On Thu, 14 May 2020 18:52:09 +, Gerhard adam wrote: > > It is easy to say that a COBOL program needs to “know” this but it is > nonsense since there is nothing a COBOL program can do with this info. > It could print it in a report. I suspect cultural familiarity, the complement of a presentation I attended circa 1980 where IBM was selling a then-innovative online service. The presenter said the base subscription entitled the customer to one megabyte of storage. Question from the audience: "How much is that in cylinders?" Of course, it depends. 1.75 cylinders. Someone with a different background might have been familiar with 1.36 floppy disks. >If it turns out to really be necessary then a subroutine can be written (as it >has been done for decades) to provide this information. >If the question is simply to bitch about why z/OS does do this automatically >via a call or something then the complaint is directed to the wrong group > Keep your data in zFS. Then "ls -l" gives the answer immediately. How readily can COBOL access zFS files. BPXWDYN should make it routine. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Activate SMS configuration in batch
If you just wanted to wait until the SETSMS command was comple you could do it with CONDOLE, but AFAIK SETSMS and SET SMS= hand off the request to an SMS address space and complete before the change is in effect. My guess is that the only way is wait for a message from SMS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Gadi Ben-Avi [gad...@malam.com] Sent: Thursday, May 14, 2020 6:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Activate SMS configuration in batch Hi, Does anyone know of a way to activate an SMS configuration in batch? I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a way that will wait until the activation is complete before continuing to the next step. We are running z/OS v2.2 Thanks Gadi -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
It is easy to say that a COBOL program needs to “know” this but it is nonsense since there is nothing a COBOL program can do with this info. If it turns out to really be necessary then a subroutine can be written (as it has been done for decades) to provide this information. If the question is simply to bitch about why z/OS does do this automatically via a call or something then the complaint is directed to the wrong group Get Outlook for iOS On Thu, May 14, 2020 at 11:43 AM -0700, "Seymour J Metz" wrote: Because the information that he's asking for isn't in the catalog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Thursday, May 14, 2020 2:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? I dont see why you cant just call IDCAMS in batch (regardless of the language used) and get the file size from the catalog? Joe On Thu, May 14, 2020 at 1:16 PM Seymour J Metz wrote: > That wasn't what he wrote, but I agree that it could have been phrased > better. Still, the question is relevant; if we (TINW) knew why the OP was > asking and what was behind his question, we would be better positioned to > address the underlying problem. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" > Well gee, I would guess because the application that needs to know is > already written -- and it's written in COBOL. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: Thursday, May 14, 2020 10:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > It is very common for someone with a problem to assume that it has to be > fixed in a certain way, and to ask about that way rather than the actual > problem. Asking for clarification never hurts, and often helps. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of > Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > Of course it does not matter to COBOL! > > But it might matter to one or more applications that might just happen to > be > written in COBOL! > > No disrespect @Gil but this kind of answer drives me crazy. One thinks > about > a problem. It is a big and complex problem with multiple unknowns and > tradeoffs. There are many ways one might at least partially solve it. One > thinks at length about all the tradeoffs. One finally drills down on one > particular approach ... but wait! There is one detail necessary for the > solution to work that one does not know. > > So one posts on IBMMAIN "how can a COBOL program running as a started task > but not APF-authorized determine how many widgets are in a bushel?" > > And someone immediately replies "why would you want to do that?" > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Thursday, May 14, 2020 9:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: > > >Thanks Lizette, I had forgotten about LISTDSI. The context here was a > need > for an API callable from a batch COBOL program, but that could be done too, > if somewhat clumsily due to the requirement for LISTDSI to be executed in a > TSO environment. > > > >I sent my co-worker on a search at cbttape.org for something he could > use. > > > Why? Where does this matter to COBOL? > > The VTOC-based approaches give at least an upper bound, which might > suffice for capacity calculations. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Rightfully people would like to know what the purpose is. It isn’t simply a question of acquiring the info, but also what you intend to do about it afterwards. Since the question pertains to COBOL I’m guessing they haven’t thought that far ahead Get Outlook for iOS On Thu, May 14, 2020 at 11:16 AM -0700, "Seymour J Metz" wrote: That wasn't what he wrote, but I agree that it could have been phrased better. Still, the question is relevant; if we (TINW) knew why the OP was asking and what was behind his question, we would be better positioned to address the underlying problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 14, 2020 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" Well gee, I would guess because the application that needs to know is already written -- and it's written in COBOL. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, May 14, 2020 10:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is very common for someone with a problem to assume that it has to be fixed in a certain way, and to ask about that way rather than the actual problem. Asking for clarification never hurts, and often helps. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 14, 2020 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Of course it does not matter to COBOL! But it might matter to one or more applications that might just happen to be written in COBOL! No disrespect @Gil but this kind of answer drives me crazy. One thinks about a problem. It is a big and complex problem with multiple unknowns and tradeoffs. There are many ways one might at least partially solve it. One thinks at length about all the tradeoffs. One finally drills down on one particular approach ... but wait! There is one detail necessary for the solution to work that one does not know. So one posts on IBMMAIN "how can a COBOL program running as a started task but not APF-authorized determine how many widgets are in a bushel?" And someone immediately replies "why would you want to do that?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 14, 2020 9:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: >Thanks Lizette, I had forgotten about LISTDSI. The context here was a need for an API callable from a batch COBOL program, but that could be done too, if somewhat clumsily due to the requirement for LISTDSI to be executed in a TSO environment. > >I sent my co-worker on a search at cbttape.org for something he could use. > Why? Where does this matter to COBOL? The VTOC-based approaches give at least an upper bound, which might suffice for capacity calculations. -- 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Because the information that he's asking for isn't in the catalog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Thursday, May 14, 2020 2:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? I dont see why you cant just call IDCAMS in batch (regardless of the language used) and get the file size from the catalog? Joe On Thu, May 14, 2020 at 1:16 PM Seymour J Metz wrote: > That wasn't what he wrote, but I agree that it could have been phrased > better. Still, the question is relevant; if we (TINW) knew why the OP was > asking and what was behind his question, we would be better positioned to > address the underlying problem. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" > Well gee, I would guess because the application that needs to know is > already written -- and it's written in COBOL. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: Thursday, May 14, 2020 10:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > It is very common for someone with a problem to assume that it has to be > fixed in a certain way, and to ask about that way rather than the actual > problem. Asking for clarification never hurts, and often helps. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of > Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > Of course it does not matter to COBOL! > > But it might matter to one or more applications that might just happen to > be > written in COBOL! > > No disrespect @Gil but this kind of answer drives me crazy. One thinks > about > a problem. It is a big and complex problem with multiple unknowns and > tradeoffs. There are many ways one might at least partially solve it. One > thinks at length about all the tradeoffs. One finally drills down on one > particular approach ... but wait! There is one detail necessary for the > solution to work that one does not know. > > So one posts on IBMMAIN "how can a COBOL program running as a started task > but not APF-authorized determine how many widgets are in a bushel?" > > And someone immediately replies "why would you want to do that?" > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Thursday, May 14, 2020 9:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: > > >Thanks Lizette, I had forgotten about LISTDSI. The context here was a > need > for an API callable from a batch COBOL program, but that could be done too, > if somewhat clumsily due to the requirement for LISTDSI to be executed in a > TSO environment. > > > >I sent my co-worker on a search at cbttape.org for something he could > use. > > > Why? Where does this matter to COBOL? > > The VTOC-based approaches give at least an upper bound, which might > suffice for capacity calculations. > > -- 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 > > -- > 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
The Catalog/VVDS data for VSAM can be wrong or out of date. These fields are only updated on successful close. So, you can't count on it for files actively updated by long running tasks, or tasks that end without properly closing the VSAM files. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Allan Staller > Sent: Thursday, May 14, 2020 11:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non- > zFS, non-database files? > > That will only work for VSAM datasets. The information request by the OP is > not in the catalog for non-VSAM datasets. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joe Monk > Sent: Thursday, May 14, 2020 1:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non- > zFS, non-database files? > > [CAUTION: This Email is from outside the Organization. Unless you trust the > sender, Don’t click links or open attachments as it may be a Phishing email, > which can steal your Information and compromise your Computer.] > > I dont see why you cant just call IDCAMS in batch (regardless of the language > used) and get the file size from the catalog? > > Joe > > On Thu, May 14, 2020 at 1:16 PM Seymour J Metz > wrote: > > > That wasn't what he wrote, but I agree that it could have been phrased > > better. Still, the question is relevant; if we (TINW) knew why the OP > > was asking and what was behind his question, we would be better > > positioned to address the underlying problem. > > > > > > -- > > Shmuel (Seymour J.) Metz > > https://urldefense.com/v3/__https://apc01.safelinks.protection.outlook > > > .com/?url=http:*2F*2Fmason.g__;JSU!!JmPEgBY0HMszNaDT!6HOga4eqFzsY > hN0mk > > GQQo9qY4TuFaHGD-XHs2L158TBQDTX1_C_dAo3g33e7NQ$ > > > mu.edu%2F~smetz3&data=02%7C01%7Callan.staller%40HCL.COM%7C8 > b33a2a8 > > > 5ac64325bff108d7f833d3e5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7 > C0%7C > > > 637250773810991404&sdata=Z1A39wHlVdhE9CS1wtMzsYhLXhF9xp6qNl > nJ%2BSF > > IguA%3D&reserved=0 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > > behalf of Charles Mills [charl...@mcn.org] > > Sent: Thursday, May 14, 2020 1:46 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > > non-zFS, non-database files? > > > > I hear you @Shmuel and agree, but "why does it have to be solved in > COBOL?" > > Well gee, I would guess because the application that needs to know is > > already written -- and it's written in COBOL. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of Seymour J Metz > > Sent: Thursday, May 14, 2020 10:29 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > > non-zFS, non-database files? > > > > It is very common for someone with a problem to assume that it has to > > be fixed in a certain way, and to ask about that way rather than the > > actual problem. Asking for clarification never hurts, and often helps. > > > > > > -- > > Shmuel (Seymour J.) Metz > > https://urldefense.com/v3/__https://apc01.safelinks.protection.outlook > > > .com/?url=http:*2F*2Fmason.g__;JSU!!JmPEgBY0HMszNaDT!6HOga4eqFzsY > hN0mk > > GQQo9qY4TuFaHGD-XHs2L158TBQDTX1_C_dAo3g33e7NQ$ > > > mu.edu%2F~smetz3&data=02%7C01%7Callan.staller%40HCL.COM%7C8 > b33a2a8 > > > 5ac64325bff108d7f833d3e5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7 > C0%7C > > > 637250773811001359&sdata=LJ6EoxSkEHBr74x9XK3%2B6bybH2mZOI%2 > FsKqDEK > > TWV5xQ%3D&reserved=0 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > > behalf of Charles Mills [charl...@mcn.org] > > Sent: Thursday, May 14, 2020 1:25 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > > non-zFS, non-database files? > > > > Of course it does not matter to COBOL! > > > > But it might matter to one or more applications that might just happen > > to be written in COBOL! > > > > No disrespect @Gil but this kind of answer drives me crazy. One thinks > > about a problem. It is a big and complex problem with multiple > > unknowns and tradeoffs. There are many ways one might at least > > partially solve it. One thinks at length about all the tradeoffs. One > > finally drills down on one particular approach ... but wait! There is > > one detail necessary for the solution to work that one does not know. > > > > So one posts on IBMMAIN "how can a COBOL program running as a started > > task but not APF-authorized determine how many widgets are in a > bushel?" > > > > And someone immediately replies "why would you want to do that?" > > > > Charles > > > > > > -Original Message- > > From: IBM Mai
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
He wants NON VSAM - which is why I suggested to REXX to use LISTDSI But there might be other functions on CBTTAPE.ORG that might be useful Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Thursday, May 14, 2020 11:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? I dont see why you cant just call IDCAMS in batch (regardless of the language used) and get the file size from the catalog? Joe On Thu, May 14, 2020 at 1:16 PM Seymour J Metz wrote: > That wasn't what he wrote, but I agree that it could have been phrased > better. Still, the question is relevant; if we (TINW) knew why the OP > was asking and what was behind his question, we would be better > positioned to address the underlying problem. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" > Well gee, I would guess because the application that needs to know is > already written -- and it's written in COBOL. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Seymour J Metz > Sent: Thursday, May 14, 2020 10:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > It is very common for someone with a problem to assume that it has to > be fixed in a certain way, and to ask about that way rather than the > actual problem. Asking for clarification never hurts, and often helps. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > Of course it does not matter to COBOL! > > But it might matter to one or more applications that might just happen > to be written in COBOL! > > No disrespect @Gil but this kind of answer drives me crazy. One thinks > about a problem. It is a big and complex problem with multiple > unknowns and tradeoffs. There are many ways one might at least > partially solve it. One thinks at length about all the tradeoffs. One > finally drills down on one particular approach ... but wait! There is > one detail necessary for the solution to work that one does not know. > > So one posts on IBMMAIN "how can a COBOL program running as a started > task but not APF-authorized determine how many widgets are in a bushel?" > > And someone immediately replies "why would you want to do that?" > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Thursday, May 14, 2020 9:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: > > >Thanks Lizette, I had forgotten about LISTDSI. The context here was > >a > need > for an API callable from a batch COBOL program, but that could be done > too, if somewhat clumsily due to the requirement for LISTDSI to be > executed in a TSO environment. > > > >I sent my co-worker on a search at cbttape.org for something he could > use. > > > Why? Where does this matter to COBOL? > > The VTOC-based approaches give at least an upper bound, which might > suffice for capacity calculations. > > -- 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 > > -- > 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
That will only work for VSAM datasets. The information request by the OP is not in the catalog for non-VSAM datasets. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Thursday, May 14, 2020 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I dont see why you cant just call IDCAMS in batch (regardless of the language used) and get the file size from the catalog? Joe On Thu, May 14, 2020 at 1:16 PM Seymour J Metz wrote: > That wasn't what he wrote, but I agree that it could have been phrased > better. Still, the question is relevant; if we (TINW) knew why the OP > was asking and what was behind his question, we would be better > positioned to address the underlying problem. > > > -- > Shmuel (Seymour J.) Metz > https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g > mu.edu%2F~smetz3&data=02%7C01%7Callan.staller%40HCL.COM%7C8b33a2a8 > 5ac64325bff108d7f833d3e5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C > 637250773810991404&sdata=Z1A39wHlVdhE9CS1wtMzsYhLXhF9xp6qNlnJ%2BSF > IguA%3D&reserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" > Well gee, I would guess because the application that needs to know is > already written -- and it's written in COBOL. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Seymour J Metz > Sent: Thursday, May 14, 2020 10:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > It is very common for someone with a problem to assume that it has to > be fixed in a certain way, and to ask about that way rather than the > actual problem. Asking for clarification never hurts, and often helps. > > > -- > Shmuel (Seymour J.) Metz > https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g > mu.edu%2F~smetz3&data=02%7C01%7Callan.staller%40HCL.COM%7C8b33a2a8 > 5ac64325bff108d7f833d3e5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C > 637250773811001359&sdata=LJ6EoxSkEHBr74x9XK3%2B6bybH2mZOI%2FsKqDEK > TWV5xQ%3D&reserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > Of course it does not matter to COBOL! > > But it might matter to one or more applications that might just happen > to be written in COBOL! > > No disrespect @Gil but this kind of answer drives me crazy. One thinks > about a problem. It is a big and complex problem with multiple > unknowns and tradeoffs. There are many ways one might at least > partially solve it. One thinks at length about all the tradeoffs. One > finally drills down on one particular approach ... but wait! There is > one detail necessary for the solution to work that one does not know. > > So one posts on IBMMAIN "how can a COBOL program running as a started > task but not APF-authorized determine how many widgets are in a bushel?" > > And someone immediately replies "why would you want to do that?" > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Thursday, May 14, 2020 9:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: > > >Thanks Lizette, I had forgotten about LISTDSI. The context here was > >a > need > for an API callable from a batch COBOL program, but that could be done > too, if somewhat clumsily due to the requirement for LISTDSI to be > executed in a TSO environment. > > > >I sent my co-worker on a search at cbttape.org for something he could > use. > > > Why? Where does this matter to COBOL? > > The VTOC-based approaches give at least an upper bound, which might > suffice for capacity calculations. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with t
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
I dont see why you cant just call IDCAMS in batch (regardless of the language used) and get the file size from the catalog? Joe On Thu, May 14, 2020 at 1:16 PM Seymour J Metz wrote: > That wasn't what he wrote, but I agree that it could have been phrased > better. Still, the question is relevant; if we (TINW) knew why the OP was > asking and what was behind his question, we would be better positioned to > address the underlying problem. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" > Well gee, I would guess because the application that needs to know is > already written -- and it's written in COBOL. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: Thursday, May 14, 2020 10:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > It is very common for someone with a problem to assume that it has to be > fixed in a certain way, and to ask about that way rather than the actual > problem. Asking for clarification never hurts, and often helps. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of > Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > Of course it does not matter to COBOL! > > But it might matter to one or more applications that might just happen to > be > written in COBOL! > > No disrespect @Gil but this kind of answer drives me crazy. One thinks > about > a problem. It is a big and complex problem with multiple unknowns and > tradeoffs. There are many ways one might at least partially solve it. One > thinks at length about all the tradeoffs. One finally drills down on one > particular approach ... but wait! There is one detail necessary for the > solution to work that one does not know. > > So one posts on IBMMAIN "how can a COBOL program running as a started task > but not APF-authorized determine how many widgets are in a bushel?" > > And someone immediately replies "why would you want to do that?" > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Thursday, May 14, 2020 9:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: > > >Thanks Lizette, I had forgotten about LISTDSI. The context here was a > need > for an API callable from a batch COBOL program, but that could be done too, > if somewhat clumsily due to the requirement for LISTDSI to be executed in a > TSO environment. > > > >I sent my co-worker on a search at cbttape.org for something he could > use. > > > Why? Where does this matter to COBOL? > > The VTOC-based approaches give at least an upper bound, which might > suffice for capacity calculations. > > -- 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 > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
That wasn't what he wrote, but I agree that it could have been phrased better. Still, the question is relevant; if we (TINW) knew why the OP was asking and what was behind his question, we would be better positioned to address the underlying problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 14, 2020 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" Well gee, I would guess because the application that needs to know is already written -- and it's written in COBOL. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, May 14, 2020 10:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is very common for someone with a problem to assume that it has to be fixed in a certain way, and to ask about that way rather than the actual problem. Asking for clarification never hurts, and often helps. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 14, 2020 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Of course it does not matter to COBOL! But it might matter to one or more applications that might just happen to be written in COBOL! No disrespect @Gil but this kind of answer drives me crazy. One thinks about a problem. It is a big and complex problem with multiple unknowns and tradeoffs. There are many ways one might at least partially solve it. One thinks at length about all the tradeoffs. One finally drills down on one particular approach ... but wait! There is one detail necessary for the solution to work that one does not know. So one posts on IBMMAIN "how can a COBOL program running as a started task but not APF-authorized determine how many widgets are in a bushel?" And someone immediately replies "why would you want to do that?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 14, 2020 9:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: >Thanks Lizette, I had forgotten about LISTDSI. The context here was a need for an API callable from a batch COBOL program, but that could be done too, if somewhat clumsily due to the requirement for LISTDSI to be executed in a TSO environment. > >I sent my co-worker on a search at cbttape.org for something he could use. > Why? Where does this matter to COBOL? The VTOC-based approaches give at least an upper bound, which might suffice for capacity calculations. -- 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 -- 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: USS Open in SYSCALL ENV
There's cleverness and there's glitz; they're not the same modern e-mail clients have lots of glitz and very little cleverness. A clever client makes it easy to do what you need to do, doesn't automatically do things that you shouldn't be doing and gives unobtrusive feedback when you do something questionable. And, yes, exact quotes are much more useful than paraphrases when you're trying to shoot a problem. For REXX issues I always like to see the results with trace i active and for HLASM I like to see both the source and the relevant lines from the listing; sometimes the latter isn't what I expect it to be, and that can help pinpoint the problem. But I'm preaching to the quire. -- 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, May 14, 2020 1:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: USS Open in SYSCALL ENV On Thu, 14 May 2020 17:26:28 +, Seymour J Metz wrote: >> The OP's command is not valid REXX. However, the original code was > >'open' path, > O_rdwr+O_creat+O_trunc, > 755 > >and *that* is valid; the commas are continuation characters. > I did not see that in his first submission: Date: Thu, 14 May 2020 07:53:33 -0500 ... either in the email distribution or on the LISTSERV website. Where did you see it? Ah! I see he linked to it in a followup, but copied it carelessly in a followup. Contributors should be fastidious in posting exact copies of the code in question, ideally by copy-and-paste from a log or SYSPRINT. Turn off all the "smart" formatting options. Alas, carriage returns are becoming a lost art, an MUAs value cleverness over precision. -- 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: USS Open in SYSCALL ENV
On Thu, 14 May 2020 17:26:28 +, Seymour J Metz wrote: >> The OP's command is not valid REXX. However, the original code was > >'open' path, > O_rdwr+O_creat+O_trunc, > 755 > >and *that* is valid; the commas are continuation characters. > I did not see that in his first submission: Date: Thu, 14 May 2020 07:53:33 -0500 ... either in the email distribution or on the LISTSERV website. Where did you see it? Ah! I see he linked to it in a followup, but copied it carelessly in a followup. Contributors should be fastidious in posting exact copies of the code in question, ideally by copy-and-paste from a log or SYSPRINT. Turn off all the "smart" formatting options. Alas, carriage returns are becoming a lost art, an MUAs value cleverness over precision. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" Well gee, I would guess because the application that needs to know is already written -- and it's written in COBOL. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, May 14, 2020 10:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is very common for someone with a problem to assume that it has to be fixed in a certain way, and to ask about that way rather than the actual problem. Asking for clarification never hurts, and often helps. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 14, 2020 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Of course it does not matter to COBOL! But it might matter to one or more applications that might just happen to be written in COBOL! No disrespect @Gil but this kind of answer drives me crazy. One thinks about a problem. It is a big and complex problem with multiple unknowns and tradeoffs. There are many ways one might at least partially solve it. One thinks at length about all the tradeoffs. One finally drills down on one particular approach ... but wait! There is one detail necessary for the solution to work that one does not know. So one posts on IBMMAIN "how can a COBOL program running as a started task but not APF-authorized determine how many widgets are in a bushel?" And someone immediately replies "why would you want to do that?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 14, 2020 9:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: >Thanks Lizette, I had forgotten about LISTDSI. The context here was a need for an API callable from a batch COBOL program, but that could be done too, if somewhat clumsily due to the requirement for LISTDSI to be executed in a TSO environment. > >I sent my co-worker on a search at cbttape.org for something he could use. > Why? Where does this matter to COBOL? The VTOC-based approaches give at least an upper bound, which might suffice for capacity calculations. -- 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 -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
It is very common for someone with a problem to assume that it has to be fixed in a certain way, and to ask about that way rather than the actual problem. Asking for clarification never hurts, and often helps. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 14, 2020 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Of course it does not matter to COBOL! But it might matter to one or more applications that might just happen to be written in COBOL! No disrespect @Gil but this kind of answer drives me crazy. One thinks about a problem. It is a big and complex problem with multiple unknowns and tradeoffs. There are many ways one might at least partially solve it. One thinks at length about all the tradeoffs. One finally drills down on one particular approach ... but wait! There is one detail necessary for the solution to work that one does not know. So one posts on IBMMAIN "how can a COBOL program running as a started task but not APF-authorized determine how many widgets are in a bushel?" And someone immediately replies "why would you want to do that?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 14, 2020 9:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: >Thanks Lizette, I had forgotten about LISTDSI. The context here was a need >for an API callable from a batch COBOL program, but that could be done too, if >somewhat clumsily due to the requirement for LISTDSI to be executed in a TSO >environment. > >I sent my co-worker on a search at cbttape.org for something he could use. > Why? Where does this matter to COBOL? The VTOC-based approaches give at least an upper bound, which might suffice for capacity calculations. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Open in SYSCALL ENV
> The OP's command is not valid REXX. However, the original code was
'open' path,
O_rdwr+O_creat+O_trunc,
755
and *that* is valid; the commas are continuation characters.
--
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, May 14, 2020 12:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS Open in SYSCALL ENV
On Thu, 14 May 2020 14:58:27 +, Seymour J Metz wrote:
>The first thing I don't understand is the order of the code. Shouldn't the
>syscalls('ON') come before Address SYSCALL 'readdir 'BGZUSDIR' ls. lsst.'?
>OTOH, the code is looking where it should for the FD.
>
I suspect it doesn't matter. address SYSCALL command blind-dubs the TCB.
I'm quite suspicious of the commas. In a command, I'd expect
them to result in Rexx syntax errors.
But prior to SYSCALLS('ON') the SYSCALL constants are defined only in the
shell environment. I think he clarified to UNIX.
Context; Le bon Dieu est dans le détail. So:
SIGNAL ON NOVALUE /* Always, for debugging! */
PARSE SOURCE . /* Where are we? */
/* Then your sample code; post the trace. */
>TSO doesn't create file descriptors, so an FD of 0 is what I would expect
>calling the code from ISPF.
>
>
>From: Michael Babcock
>Sent: Thursday, May 14, 2020 10:46 AM
>
>Sorry Yes Unix System Services.
>
>>
>> From: Michael Babcock
>> Sent: Thursday, May 14, 2020 8:53 AM
>>
>> In the USS REXX SYSCALL environment, is it normal for a command such as:
>>
>> open /u/xx35/test, o_rdwr+o_creat+o_trunc, 755
>>
>> To return a file descriptor of 0 (zero)?
>>
>> The reason I ask is that the subsequent write fails with
>>
>> RC 71 RSN 571011C
>>
>> Which basically says: file is not opened
>>
>> I thought fd 0 is normally STDIN.
-- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Of course it does not matter to COBOL! But it might matter to one or more applications that might just happen to be written in COBOL! No disrespect @Gil but this kind of answer drives me crazy. One thinks about a problem. It is a big and complex problem with multiple unknowns and tradeoffs. There are many ways one might at least partially solve it. One thinks at length about all the tradeoffs. One finally drills down on one particular approach ... but wait! There is one detail necessary for the solution to work that one does not know. So one posts on IBMMAIN "how can a COBOL program running as a started task but not APF-authorized determine how many widgets are in a bushel?" And someone immediately replies "why would you want to do that?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 14, 2020 9:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: >Thanks Lizette, I had forgotten about LISTDSI. The context here was a need >for an API callable from a batch COBOL program, but that could be done too, if >somewhat clumsily due to the requirement for LISTDSI to be executed in a TSO >environment. > >I sent my co-worker on a search at cbttape.org for something he could use. > Why? Where does this matter to COBOL? The VTOC-based approaches give at least an upper bound, which might suffice for capacity calculations. -- 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: Question on wrapped JESMSGLG messages
Thanks, Shmuel; now that I have some place to look, I think I will be fine from here. Don Johnson On Thu, May 14, 2020 at 10:03 AM Seymour J Metz wrote: > The formatting of the messages is a console function, not a JES function, > and is driven by parameters on the WTO macro and by how you are configured. > One of the options is ulti-line WTO and, AFAIK, there is no COBOL support > for it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Donald Johnson Jr. [02ee771a0785-dmarc-requ...@listserv.ua.edu] > Sent: Thursday, May 14, 2020 9:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Question on wrapped JESMSGLG messages > > I have a peculiar question and hope the answer is easily found in this > group. Looking at these highlighted values > > 08.17.38 JOB57837 DJMU2DF:DB01900I - MUF > DJMU2DF,99,NO > 08.17.38 JOB57837 DJMU2DF:DB01909E - * > - ASTERISK 682 >682 POINTS NEAR ERROR > > > 08.05.17 JOB57048 IEC161I 056-084,CICSABCD,$$@ $$@,DFHLCD,,, 571 > >571 IEC161I OMY.CICS.DFHLCD,OMY.CICS.DFHLCD.DATA, >571 IEC161I ICF.ABCD.USERCAT > > I know that the number is a cross-reference for continued lines in Syslog > and the user joblog, and I have never thought twice about it before. > However, I have someone asking about this, and I realized that I don't > really know how it works. My questions are: > > 1. What drives this process? I assume it is part of JES message handling > 2. Is the line length before wrapping a message held in a parameter > somewhere? > 3. What causes some messages to use the #, and others to just wrap. For > example, if I write a COBOL program with DISPLAY...UPON CONSOLE, the lines > just wrap in the Syslog, with no ### identifier. Other jobs or STCs write > messages like the above, with the continuation number. > 4. Is there some doc I can point to for my colleague to understand this? We > all know what it is, and most of us probably don't care how it works, but I > figure that someone knows what this is called, how it is configured, and > how it works for different messages. > > Thanks all! > Don > > Don Johnson > > Broadcom > donald.johnso...@broadcom.com | broadcom.com > > -- > 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: Activate SMS configuration in batch
Neither of those address the OP's question: how to issue the command AND WAIT
for the configuration change to take effect.
Oh, BTW, "CART before the horse" was a pun that already referred to CONSOLE,
but CONSOLE by itself doesn't solve the problem.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Steve Smith [sasd...@gmail.com]
Sent: Thursday, May 14, 2020 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Activate SMS configuration in batch
For the simple case where you want to issue some commands at a particular
point in a batch job, it's easy enough to just use IEBGENER or something to
copy JCL commands to INTRDR.
For the complex cases, the CONSOLE command provides plenty of
functionality, and can be fairly easily programmed with REXX.
sas
On Thu, May 14, 2020 at 12:00 PM Seymour J Metz wrote:
> That's putting the CART before the horse. The problem isn't issuing the
> command, but waiting for initialization to complete.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf
> of Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
> Sent: Thursday, May 14, 2020 11:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Activate SMS configuration in batch
>
> Just highlights the need for an IBM provided "command issuer" instead of
> everyone rolling their own. I personally like using the ISFSLASH
> facilities for that. Uses the user's access to validate authority. I've
> posted this before, which I stole from somewhere else, and tweaked it a
> bit. I wish I had REXX compiler.
>
> /* REXX */
> /* this REXX exec will issue operator commands via SDSF REXX interface
>security is based on the person using the command. this exec is to be
>used for batch only */
> 'EXECIO * DISKR SYSIN (STEM mycmd. FINIS'
> if rc > 0 then do
>say 'Return code from OPEN was' rc
>say 'Aborting...'
>exit
>end
>
> /* Allocate results output file */
> Call BPXWDYN "alloc rtddn(ddnm) sysout"
>
> /* Process all input commands*/
> Do c=1 to mycmd.0
> oper_command.0 = 1
> oper_command.1 = mycmd.c
> Call Main_process
> End
>
> /* Free results output file */
> Call BPXWDYN "free fi(ddnm)"
> Return 0
>
> Main_process:
> /* process all data from SYSIN */
> rc=isfcalls('ON')
> Address SDSF ISFSLASH "("oper_command.") (WAIT)"
> l_cnt = 0
> If datatype(isfulog.0) = "NUM" Then Do
> If isfulog.0 <> 0 Then Do
> l_cnt = l_cnt + 1
> l.l_cnt = substr(isfulog.1,1,43)
> Do ix=1 to isfulog.0
>ll = length(isfulog.ix)
>if ll <> 0 Then
> qdata = substr(isfulog.ix,44,ll-43)
>else
> qdata = isfulog.ix
>l_cnt = l_cnt + 1
>l.l_cnt = qdata
> End
> End
> Else Do
> l_cnt = l_cnt + 1
> l.l_cnt = "No command response available"
> End
> End
> Else Do
> l_cnt = l_cnt + 1
> l.l_cnt = "Error in command reponse"
> End
> rc=isfcalls("OFF")
> If (l_cnt = 0) Then Do
> l_cnt = l_cnt + 1
> l.l_cnt = ' /* no data produced */'
> End
> l.0 = l_cnt
> Address MVS "ExecIO "l_cnt" DiskW "ddnm" (Finis Stem l.)"
> l_cnt = 0
> Return
>
>
>
>
> _
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand
> Rapids, MI 49546
> 616.653.8429 | fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Lizette Koehler
> Sent: Thursday, May 14, 2020 11:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Activate SMS configuration in batch
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> When using the JCL COMMAND statement, I think it gets executed as soon as
> the job hits the Internal reader and may not execute on the system you want
> it on. Worth testing it out.
>
> Do you have any automation tools?
>
> With CA OPS/MVS I have an MSF Plex that allows me to ship commands to any
> LPAR that MSF is able to see. That way my commands do not get issued until
> my batch job runs.
>
>
> Lizette
>
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of R.S.
> Sent: Thursday, May 14, 2020 6:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Activate SMS configuration in batch
>
> W dniu 14.05.2020 o 12:43, Gadi Ben-Avi pisze:
> > Hi,
> > Does anyone know of a way to activate an SMS configuration in batch?
> >
> > I know I can issue the SETSMS SCDS(xx) command in batch, but I am long
> > for
> a way that will wait until the activation is complete before continuing to
> the next step.
> >
> > We are running z/OS v2.2
> >
> >
> What about
> // COMMAND
> ?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: >Thanks Lizette, I had forgotten about LISTDSI. The context here was a need >for an API callable from a batch COBOL program, but that could be done too, if >somewhat clumsily due to the requirement for LISTDSI to be executed in a TSO >environment. > >I sent my co-worker on a search at cbttape.org for something he could use. > Why? Where does this matter to COBOL? The VTOC-based approaches give at least an upper bound, which might suffice for capacity calculations. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
I think the bottom line is that there is no single guaranteed perfect method, but depending on what your need is there may be an adequate solution (as suggested by the other replies). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Thursday, May 14, 2020 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? This question came to me from a co-worker: Is there any API to get the byte file size of a non-VSAM, non-zFS, non-database file in z/OS? I.E., byte file size for plain sequential files? I am aware of the "old way" of reading the VTOC of a volume to get the various DSCB's that total up disk extents, but that gets complicated quickly for multi-volume files, and was never guaranteed to be accurate as to the actual byte count of data in the file except in the RECFM=FS/FBS case anyway. There is always the performance-killing option of just reading the whole file and totaling up the length of every record (or block depending on how you structure the reads), but no one would call that an API. As far as I know there is no such API in z/OS, and this is what I told my co-worker, but am I wrong? Is there an alternative of which I am not aware? TIA for your input. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Thanks Lizette, I had forgotten about LISTDSI. The context here was a need for an API callable from a batch COBOL program, but that could be done too, if somewhat clumsily due to the requirement for LISTDSI to be executed in a TSO environment. I sent my co-worker on a search at cbttape.org for something he could use. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Thursday, May 14, 2020 12:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Well you might consider a REXX solution. For NON-VSAM on DISK you can use the LISTDSI command then convert tracks to bytes but using 1 Track = 56664 bytes For VSAM I do a LISTC and search for H-A--RBA and HI-U-RBA that is in bytes But not sure about an API that is available. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 Sent: Thursday, May 14, 2020 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? This question came to me from a co-worker: Is there any API to get the byte file size of a non-VSAM, non-zFS, non-database file in z/OS? I.E., byte file size for plain sequential files? I am aware of the "old way" of reading the VTOC of a volume to get the various DSCB's that total up disk extents, but that gets complicated quickly for multi-volume files, and was never guaranteed to be accurate as to the actual byte count of data in the file except in the RECFM=FS/FBS case anyway. There is always the performance-killing option of just reading the whole file and totaling up the length of every record (or block depending on how you structure the reads), but no one would call that an API. As far as I know there is no such API in z/OS, and this is what I told my co-worker, but am I wrong? Is there an alternative of which I am not aware? TIA for your input. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Maybe the Catalog Search Function (CSI) might be able to help. See it that could be something usable Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 14, 2020 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? No, and I'm not even sure what the question means. If what you want is the sum of the record lengths then you have to read through the entire file and add up the lengths. If you want to know how big it will look to a Unix application hen you'll need to add the number of records to account for the LF or NL characters, unless the application is reading it as binary. The one exception is that if it is a valid FBS dataset then you can calculate the size. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Thursday, May 14, 2020 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? This question came to me from a co-worker: Is there any API to get the byte file size of a non-VSAM, non-zFS, non-database file in z/OS? I.E., byte file size for plain sequential files? I am aware of the "old way" of reading the VTOC of a volume to get the various DSCB's that total up disk extents, but that gets complicated quickly for multi-volume files, and was never guaranteed to be accurate as to the actual byte count of data in the file except in the RECFM=FS/FBS case anyway. There is always the performance-killing option of just reading the whole file and totaling up the length of every record (or block depending on how you structure the reads), but no one would call that an API. As far as I know there is no such API in z/OS, and this is what I told my co-worker, but am I wrong? Is there an alternative of which I am not aware? TIA for your input. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
No, and I'm not even sure what the question means. If what you want is the sum of the record lengths then you have to read through the entire file and add up the lengths. If you want to know how big it will look to a Unix application hen you'll need to add the number of records to account for the LF or NL characters, unless the application is reading it as binary. The one exception is that if it is a valid FBS dataset then you can calculate the size. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Thursday, May 14, 2020 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? This question came to me from a co-worker: Is there any API to get the byte file size of a non-VSAM, non-zFS, non-database file in z/OS? I.E., byte file size for plain sequential files? I am aware of the "old way" of reading the VTOC of a volume to get the various DSCB's that total up disk extents, but that gets complicated quickly for multi-volume files, and was never guaranteed to be accurate as to the actual byte count of data in the file except in the RECFM=FS/FBS case anyway. There is always the performance-killing option of just reading the whole file and totaling up the length of every record (or block depending on how you structure the reads), but no one would call that an API. As far as I know there is no such API in z/OS, and this is what I told my co-worker, but am I wrong? Is there an alternative of which I am not aware? TIA for your input. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: USS Open in SYSCALL ENV
On Thu, 14 May 2020 14:58:27 +, Seymour J Metz wrote:
>The first thing I don't understand is the order of the code. Shouldn't the
>syscalls('ON') come before Address SYSCALL 'readdir 'BGZUSDIR' ls. lsst.'?
>OTOH, the code is looking where it should for the FD.
>
I suspect it doesn't matter. address SYSCALL command blind-dubs the TCB.
I'm quite suspicious of the commas. In a command, I'd expect
them to result in Rexx syntax errors.
But prior to SYSCALLS('ON') the SYSCALL constants are defined only in the
shell environment. I think he clarified to UNIX.
Context; Le bon Dieu est dans le détail. So:
SIGNAL ON NOVALUE /* Always, for debugging! */
PARSE SOURCE . /* Where are we? */
/* Then your sample code; post the trace. */
>TSO doesn't create file descriptors, so an FD of 0 is what I would expect
>calling the code from ISPF.
>
>
>From: Michael Babcock
>Sent: Thursday, May 14, 2020 10:46 AM
>
>Sorry Yes Unix System Services.
>
>>
>> From: Michael Babcock
>> Sent: Thursday, May 14, 2020 8:53 AM
>>
>> In the USS REXX SYSCALL environment, is it normal for a command such as:
>>
>> open /u/xx35/test, o_rdwr+o_creat+o_trunc, 755
>>
>> To return a file descriptor of 0 (zero)?
>>
>> The reason I ask is that the subsequent write fails with
>>
>> RC 71 RSN 571011C
>>
>> Which basically says: file is not opened
>>
>> I thought fd 0 is normally STDIN.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Activate SMS configuration in batch
For the simple case where you want to issue some commands at a particular
point in a batch job, it's easy enough to just use IEBGENER or something to
copy JCL commands to INTRDR.
For the complex cases, the CONSOLE command provides plenty of
functionality, and can be fairly easily programmed with REXX.
sas
On Thu, May 14, 2020 at 12:00 PM Seymour J Metz wrote:
> That's putting the CART before the horse. The problem isn't issuing the
> command, but waiting for initialization to complete.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf
> of Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
> Sent: Thursday, May 14, 2020 11:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Activate SMS configuration in batch
>
> Just highlights the need for an IBM provided "command issuer" instead of
> everyone rolling their own. I personally like using the ISFSLASH
> facilities for that. Uses the user's access to validate authority. I've
> posted this before, which I stole from somewhere else, and tweaked it a
> bit. I wish I had REXX compiler.
>
> /* REXX */
> /* this REXX exec will issue operator commands via SDSF REXX interface
>security is based on the person using the command. this exec is to be
>used for batch only */
> 'EXECIO * DISKR SYSIN (STEM mycmd. FINIS'
> if rc > 0 then do
>say 'Return code from OPEN was' rc
>say 'Aborting...'
>exit
>end
>
> /* Allocate results output file */
> Call BPXWDYN "alloc rtddn(ddnm) sysout"
>
> /* Process all input commands*/
> Do c=1 to mycmd.0
> oper_command.0 = 1
> oper_command.1 = mycmd.c
> Call Main_process
> End
>
> /* Free results output file */
> Call BPXWDYN "free fi(ddnm)"
> Return 0
>
> Main_process:
> /* process all data from SYSIN */
> rc=isfcalls('ON')
> Address SDSF ISFSLASH "("oper_command.") (WAIT)"
> l_cnt = 0
> If datatype(isfulog.0) = "NUM" Then Do
> If isfulog.0 <> 0 Then Do
> l_cnt = l_cnt + 1
> l.l_cnt = substr(isfulog.1,1,43)
> Do ix=1 to isfulog.0
>ll = length(isfulog.ix)
>if ll <> 0 Then
> qdata = substr(isfulog.ix,44,ll-43)
>else
> qdata = isfulog.ix
>l_cnt = l_cnt + 1
>l.l_cnt = qdata
> End
> End
> Else Do
> l_cnt = l_cnt + 1
> l.l_cnt = "No command response available"
> End
> End
> Else Do
> l_cnt = l_cnt + 1
> l.l_cnt = "Error in command reponse"
> End
> rc=isfcalls("OFF")
> If (l_cnt = 0) Then Do
> l_cnt = l_cnt + 1
> l.l_cnt = ' /* no data produced */'
> End
> l.0 = l_cnt
> Address MVS "ExecIO "l_cnt" DiskW "ddnm" (Finis Stem l.)"
> l_cnt = 0
> Return
>
>
>
>
> _
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand
> Rapids, MI 49546
> 616.653.8429 | fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Lizette Koehler
> Sent: Thursday, May 14, 2020 11:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Activate SMS configuration in batch
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> When using the JCL COMMAND statement, I think it gets executed as soon as
> the job hits the Internal reader and may not execute on the system you want
> it on. Worth testing it out.
>
> Do you have any automation tools?
>
> With CA OPS/MVS I have an MSF Plex that allows me to ship commands to any
> LPAR that MSF is able to see. That way my commands do not get issued until
> my batch job runs.
>
>
> Lizette
>
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of R.S.
> Sent: Thursday, May 14, 2020 6:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Activate SMS configuration in batch
>
> W dniu 14.05.2020 o 12:43, Gadi Ben-Avi pisze:
> > Hi,
> > Does anyone know of a way to activate an SMS configuration in batch?
> >
> > I know I can issue the SETSMS SCDS(xx) command in batch, but I am long
> > for
> a way that will wait until the activation is complete before continuing to
> the next step.
> >
> > We are running z/OS v2.2
> >
> >
> What about
> // COMMAND
> ?
>
> --
> 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,
> http://secure-
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Well you might consider a REXX solution. For NON-VSAM on DISK you can use the LISTDSI command then convert tracks to bytes but using 1 Track = 56664 bytes For VSAM I do a LISTC and search for H-A--RBA and HI-U-RBA that is in bytes But not sure about an API that is available. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 Sent: Thursday, May 14, 2020 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? This question came to me from a co-worker: Is there any API to get the byte file size of a non-VSAM, non-zFS, non-database file in z/OS? I.E., byte file size for plain sequential files? I am aware of the "old way" of reading the VTOC of a volume to get the various DSCB's that total up disk extents, but that gets complicated quickly for multi-volume files, and was never guaranteed to be accurate as to the actual byte count of data in the file except in the RECFM=FS/FBS case anyway. There is always the performance-killing option of just reading the whole file and totaling up the length of every record (or block depending on how you structure the reads), but no one would call that an API. As far as I know there is no such API in z/OS, and this is what I told my co-worker, but am I wrong? Is there an alternative of which I am not aware? TIA for your input. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: Activate SMS configuration in batch
That's putting the CART before the horse. The problem isn't issuing the
command, but waiting for initialization to complete.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, May 14, 2020 11:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Activate SMS configuration in batch
Just highlights the need for an IBM provided "command issuer" instead of
everyone rolling their own. I personally like using the ISFSLASH facilities
for that. Uses the user's access to validate authority. I've posted this
before, which I stole from somewhere else, and tweaked it a bit. I wish I had
REXX compiler.
/* REXX */
/* this REXX exec will issue operator commands via SDSF REXX interface
security is based on the person using the command. this exec is to be
used for batch only */
'EXECIO * DISKR SYSIN (STEM mycmd. FINIS'
if rc > 0 then do
say 'Return code from OPEN was' rc
say 'Aborting...'
exit
end
/* Allocate results output file */
Call BPXWDYN "alloc rtddn(ddnm) sysout"
/* Process all input commands*/
Do c=1 to mycmd.0
oper_command.0 = 1
oper_command.1 = mycmd.c
Call Main_process
End
/* Free results output file */
Call BPXWDYN "free fi(ddnm)"
Return 0
Main_process:
/* process all data from SYSIN */
rc=isfcalls('ON')
Address SDSF ISFSLASH "("oper_command.") (WAIT)"
l_cnt = 0
If datatype(isfulog.0) = "NUM" Then Do
If isfulog.0 <> 0 Then Do
l_cnt = l_cnt + 1
l.l_cnt = substr(isfulog.1,1,43)
Do ix=1 to isfulog.0
ll = length(isfulog.ix)
if ll <> 0 Then
qdata = substr(isfulog.ix,44,ll-43)
else
qdata = isfulog.ix
l_cnt = l_cnt + 1
l.l_cnt = qdata
End
End
Else Do
l_cnt = l_cnt + 1
l.l_cnt = "No command response available"
End
End
Else Do
l_cnt = l_cnt + 1
l.l_cnt = "Error in command reponse"
End
rc=isfcalls("OFF")
If (l_cnt = 0) Then Do
l_cnt = l_cnt + 1
l.l_cnt = ' /* no data produced */'
End
l.0 = l_cnt
Address MVS "ExecIO "l_cnt" DiskW "ddnm" (Finis Stem l.)"
l_cnt = 0
Return
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette Koehler
Sent: Thursday, May 14, 2020 11:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Activate SMS configuration in batch
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
When using the JCL COMMAND statement, I think it gets executed as soon as the
job hits the Internal reader and may not execute on the system you want it on.
Worth testing it out.
Do you have any automation tools?
With CA OPS/MVS I have an MSF Plex that allows me to ship commands to any LPAR
that MSF is able to see. That way my commands do not get issued until my batch
job runs.
Lizette
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of R.S.
Sent: Thursday, May 14, 2020 6:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Activate SMS configuration in batch
W dniu 14.05.2020 o 12:43, Gadi Ben-Avi pisze:
> Hi,
> Does anyone know of a way to activate an SMS configuration in batch?
>
> I know I can issue the SETSMS SCDS(xx) command in batch, but I am long
> for
a way that will wait until the activation is complete before continuing to the
next step.
>
> We are running z/OS v2.2
>
>
What about
// COMMAND
?
--
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,http://secure-web.cisco.com/13ldWTpJfOhvfrjYxmS8jn0qn360OWfNfCFPVYECxVJhwTnzTKipUlloblUjAXTbKREftBqcg5PgoZ9p44Lz7m-z-YXdwLc5U1C6h3IvtmzKNXXdsRyJ-16yQM1NRp4kdsmf4LVpnJku_gTiQREuPvgsSu9FYc_dHR18u0kAYoLx9ZqPfv5nK-ZtdNa_KJm2Wi0ywLDNdE-u9ssdST-0aL_YfKK05noszPogYANLux6sG8BqwMSIZBSZ2UVygInWjKjvEYmdRSvNtpk48zCxU_4S8r-tExy6nmGHFoItQHvKv-aM1CwPVUxkfnJIJlXWvBG1nZNKnJ3gVz9vkfYnALxq2oRP9-Db2xISc-6GzkG9BlaKOI7DbNJnFi4dwFrWk7MlMecbDEvXTjWEvS_iH6gtL8ExO5vNKAzAjEsvHG2Bz3CTRjajhywWwwaKz37w8/http%3A%2F%2Fwww.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 (o
Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
This question came to me from a co-worker: Is there any API to get the byte file size of a non-VSAM, non-zFS, non-database file in z/OS? I.E., byte file size for plain sequential files? I am aware of the "old way" of reading the VTOC of a volume to get the various DSCB's that total up disk extents, but that gets complicated quickly for multi-volume files, and was never guaranteed to be accurate as to the actual byte count of data in the file except in the RECFM=FS/FBS case anyway. There is always the performance-killing option of just reading the whole file and totaling up the length of every record (or block depending on how you structure the reads), but no one would call that an API. As far as I know there is no such API in z/OS, and this is what I told my co-worker, but am I wrong? Is there an alternative of which I am not aware? TIA for your input. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Activate SMS configuration in batch
This would be a great add for Naviquest. Perhaps this can get kicked around at the next Share storage Free for All. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gadi Ben-Avi Sent: Thursday, May 14, 2020 6:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Activate SMS configuration in batch Hi, Does anyone know of a way to activate an SMS configuration in batch? I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a way that will wait until the activation is complete before continuing to the next step. We are running z/OS v2.2 Thanks Gadi -- 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: Activate SMS configuration in batch
Just highlights the need for an IBM provided "command issuer" instead of
everyone rolling their own. I personally like using the ISFSLASH facilities
for that. Uses the user's access to validate authority. I've posted this
before, which I stole from somewhere else, and tweaked it a bit. I wish I had
REXX compiler.
/* REXX */
/* this REXX exec will issue operator commands via SDSF REXX interface
security is based on the person using the command. this exec is to be
used for batch only */
'EXECIO * DISKR SYSIN (STEM mycmd. FINIS'
if rc > 0 then do
say 'Return code from OPEN was' rc
say 'Aborting...'
exit
end
/* Allocate results output file */
Call BPXWDYN "alloc rtddn(ddnm) sysout"
/* Process all input commands*/
Do c=1 to mycmd.0
oper_command.0 = 1
oper_command.1 = mycmd.c
Call Main_process
End
/* Free results output file */
Call BPXWDYN "free fi(ddnm)"
Return 0
Main_process:
/* process all data from SYSIN */
rc=isfcalls('ON')
Address SDSF ISFSLASH "("oper_command.") (WAIT)"
l_cnt = 0
If datatype(isfulog.0) = "NUM" Then Do
If isfulog.0 <> 0 Then Do
l_cnt = l_cnt + 1
l.l_cnt = substr(isfulog.1,1,43)
Do ix=1 to isfulog.0
ll = length(isfulog.ix)
if ll <> 0 Then
qdata = substr(isfulog.ix,44,ll-43)
else
qdata = isfulog.ix
l_cnt = l_cnt + 1
l.l_cnt = qdata
End
End
Else Do
l_cnt = l_cnt + 1
l.l_cnt = "No command response available"
End
End
Else Do
l_cnt = l_cnt + 1
l.l_cnt = "Error in command reponse"
End
rc=isfcalls("OFF")
If (l_cnt = 0) Then Do
l_cnt = l_cnt + 1
l.l_cnt = ' /* no data produced */'
End
l.0 = l_cnt
Address MVS "ExecIO "l_cnt" DiskW "ddnm" (Finis Stem l.)"
l_cnt = 0
Return
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette Koehler
Sent: Thursday, May 14, 2020 11:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re
Re: Activate SMS configuration in batch
When using the JCL COMMAND statement, I think it gets executed as soon as the job hits the Internal reader and may not execute on the system you want it on. Worth testing it out. Do you have any automation tools? With CA OPS/MVS I have an MSF Plex that allows me to ship commands to any LPAR that MSF is able to see. That way my commands do not get issued until my batch job runs. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, May 14, 2020 6:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Activate SMS configuration in batch W dniu 14.05.2020 o 12:43, Gadi Ben-Avi pisze: > Hi, > Does anyone know of a way to activate an SMS configuration in batch? > > I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a way that will wait until the activation is complete before continuing to the next step. > > We are running z/OS v2.2 > > What about // COMMAND ? -- 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.2020 r. wynosi 169.401.468 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.401.468 as at 1 January 2020. -- 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: USS Open in SYSCALL ENV
The first thing I don't understand is the order of the code. Shouldn't the
syscalls('ON') come before Address SYSCALL 'readdir 'BGZUSDIR' ls. lsst.'?
OTOH, the code is looking where it should for the FD.
TSO doesn't create file descriptors, so an FD of 0 is what I would expect
calling the code from ISPF.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Michael Babcock [bigironp...@gmail.com]
Sent: Thursday, May 14, 2020 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: USS Open in SYSCALL ENV
Sorry Yes Unix System Services.
The code isn’t mine. It’s from IBM DBB which can be found here,
https://secure-web.cisco.com/1gI5RbPCRtzUf6FX3VBCXSQQDSNpnyDV7AevCGgQxWipNU_DbKtpM-JJ8ILA6jWQhWoazF9x962Ehp4LezNfX0_RdTKR4oDb61DN1AkD5bE5xkEJRSv50Yof7S3RhTPdhOf0q94koOjwkGJNOA0JgaUgpwUVtkNi3dPpjbYpY1bKf5zY5Rsu3ViKFY5de5EIZeJK1ef5UECATK2qGd96NbOGHrOCDjKUiSEOrzxXg5efg0PxcCDyloAUiVxiuhBZx0aEuCWe9oWy6c87qcLyNmrfE13r4gf9iIGbHJ9GfybqO2IW-RJywqcCJD0mYQS64qPzTKwawH_bj_GFn95XL0Gde-Ppcn6ZyvtE5RHypxsfeDG0RxOcx-t6d3V4XJQV77tXgI8wd-TxNRc44HHScj8L1wiMFFDq1cZbb92OULbViTGKWQafU-5TRnon4EsnX/https%3A%2F%2Fgithub.com%2FIBM%2Fdbb%2Fblob%2Fmaster%2FIDE%2FGitISPFClient%2Fsbgzexec%2Fbgzinit.rexx
I can’t reproduce the problem with some sample code I cobbled up.
On Thu, May 14, 2020 at 8:46 AM Seymour J Metz wrote:
> I assume that you mean Unix syscall environment. The documentation is a
> bit confusing, because the syscall commands set RETVAL, which is the
> behavior associated with a function. Are you looking at RC or at RETVAL?
> could you show your code? Are you running from IRXJCL, TSO or a Unix shell?
>
> My guess is that you did not invoke your code from a Unix shell and that 0
> was the first available file descriptor. If that is the case then you might
> want to open STDIN, STDOUT and STDERR at the beginning of your code.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Michael Babcock [bigironp...@gmail.com]
> Sent: Thursday, May 14, 2020 8:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: USS Open in SYSCALL ENV
>
> In the USS REXX SYSCALL environment, is it normal for a command such as:
>
> open /u/xx35/test, o_rdwr+o_creat+o_trunc, 755
>
> To return a file descriptor of 0 (zero)?
>
> The reason I ask is that the subsequent write fails with
>
> RC 71 RSN 571011C
>
> Which basically says: file is not opened
>
> I thought fd 0 is normally STDIN.
>
>
> --
> Michael Babcock
> OneMain Financial
> z/OS Systems Programmer, Lead
>
> --
> 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
>
--
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead
--
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: USS Open in SYSCALL ENV
Sorry Yes Unix System Services. The code isn’t mine. It’s from IBM DBB which can be found here, https://github.com/IBM/dbb/blob/master/IDE/GitISPFClient/sbgzexec/bgzinit.rexx I can’t reproduce the problem with some sample code I cobbled up. On Thu, May 14, 2020 at 8:46 AM Seymour J Metz wrote: > I assume that you mean Unix syscall environment. The documentation is a > bit confusing, because the syscall commands set RETVAL, which is the > behavior associated with a function. Are you looking at RC or at RETVAL? > could you show your code? Are you running from IRXJCL, TSO or a Unix shell? > > My guess is that you did not invoke your code from a Unix shell and that 0 > was the first available file descriptor. If that is the case then you might > want to open STDIN, STDOUT and STDERR at the beginning of your code. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Michael Babcock [bigironp...@gmail.com] > Sent: Thursday, May 14, 2020 8:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: USS Open in SYSCALL ENV > > In the USS REXX SYSCALL environment, is it normal for a command such as: > > open /u/xx35/test, o_rdwr+o_creat+o_trunc, 755 > > To return a file descriptor of 0 (zero)? > > The reason I ask is that the subsequent write fails with > > RC 71 RSN 571011C > > Which basically says: file is not opened > > I thought fd 0 is normally STDIN. > > > -- > Michael Babcock > OneMain Financial > z/OS Systems Programmer, Lead > > -- > 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 > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Precursors to 3540
All of the discussion of the 3540 reminded me of some older devices. Does anybody remember IEBCTRIN? How about the key-to-tape devices from UNIVAC back in the 1950s? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RES: An older device query - still using??
I'm too young to remember it, but in Poland there was very popular "key to media" solution called SeeCheck from Redifon (UK company, famous for flight simulators). It was multi-site solution. Other names were Entrex 480 or DATENSAMMELSYSTEM 620 (Nixdorf branded). Also some polish MERA was a clone of it, AFAIK. It was key to tape. 9-trk reel. However comparison 3540 to card reader clarify most of my doubts. Still have no idea about file system or other data organization ot he diskette, but this is minor issue. What I'm sure it wasn't very small MVS volume. BTW: Polish computer ODRA (ICL 1900 clone) have been used for years and last installations were using emulated card readers - it was regular PC connected using parallel port and simple PC-DOS program was there to read txt file and send it as records to the host. Or maybe it was paper tape reader emulation... -- Radoslaw Skorupka Lodz, Poland W dniu 14.05.2020 o 15:48, Bodra - Pessoal pisze: Before launch IBM 3540 Diskette Unit (could write and read floppy 8 pol disks and connected to a /370 parallel channel) after recording diskettes using IBM 3741 (single operator station) or IBM 3742 (double operator station) was necessary to move data from them to a tape reel using IBM 3747 Converter Unit. Since diskettes and tape reel could be used a lot of times, this solution brings to customers a great economy. I remember to walk in an aisle aside a Data Entry room with more them 150 IBM 3742 stations in a big bank here in Brazil, they were one of pioneers to remove old IBM 0029, IBM 0059 and IBM 0129 machines from data entry process. IBM 3540 arises to eliminated one step (convert to tape reel) and could accelerate process to make data transcript from a bunch of different forms in data to supply information to data systems. Old good time of batch processing overnight. Carlos Bodra IBM zEnterprise Certified São Paulo – SP – Brazil -Mensagem original- De: IBM Mainframe Discussion List Em nome de Tony Thigpen Enviada em: quarta-feira, 13 de maio de 2020 23:38 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: Re: An older device query - still using?? The 3540 was the reader/punch that was to replace the card reader/punch system. Which it did at both my college (while I was there) and at my first job (where it replaced the 96 column card system) just before I got there. The 3740 and 3742 were the replacement for the card punch machine. They were highly programmable. You could set up programs where some characters "punched" as packed decimal and other characters were punched as display characters. It would also sum-check fields in a single record and automatically punch final "sums records". The 3540 had a AWSOMA: Optical Media AttachTOC that contained a VOL1 record and multiple HDR1 records which supported multiple files. It had tracks and records. I am fuzzy, but I think it supported different record lengths (set in the HDR1 for each file). I know you could punch both 80 and 96 (in separate files). The VTOC design was also used in the Optical Media Attach Feature, which was actually 'emulated' on the P360/P390 in the AWSOMA dirver. (All "facts" subject to dropped memory bits due to old age.) Tony Thigpen R.S. wrote on 5/13/20 6:59 PM: I just checked bitsavers and found some information about 3540 1. Capacity - it depends. There were several types and subtypes, and sub-subtypes of diskettes. Approximately 256kB to 1,2 MB, however 3540 used only those low capacity. (details available on request) 2. Feeding media - automatically, not manually. 3. There were two types of 3540, single and double drive. 4. The purpose was to deliver data from keypunch (wrong!) data entry stations. At the times before CRT screens became popular. However still I have no idea about system support. How to write data on diskette, how to read from diskette, how to recognize volume ID, etc. No, I'm not going to use it, but I'm just curious. == 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.2020 r. wynosi 169.401.468 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
Re: Question on wrapped JESMSGLG messages
The formatting of the messages is a console function, not a JES function, and is driven by parameters on the WTO macro and by how you are configured. One of the options is ulti-line WTO and, AFAIK, there is no COBOL support for it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Donald Johnson Jr. [02ee771a0785-dmarc-requ...@listserv.ua.edu] Sent: Thursday, May 14, 2020 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question on wrapped JESMSGLG messages I have a peculiar question and hope the answer is easily found in this group. Looking at these highlighted values 08.17.38 JOB57837 DJMU2DF:DB01900I - MUF DJMU2DF,99,NO 08.17.38 JOB57837 DJMU2DF:DB01909E - * - ASTERISK 682 682 POINTS NEAR ERROR 08.05.17 JOB57048 IEC161I 056-084,CICSABCD,$$@ $$@,DFHLCD,,, 571 571 IEC161I OMY.CICS.DFHLCD,OMY.CICS.DFHLCD.DATA, 571 IEC161I ICF.ABCD.USERCAT I know that the number is a cross-reference for continued lines in Syslog and the user joblog, and I have never thought twice about it before. However, I have someone asking about this, and I realized that I don't really know how it works. My questions are: 1. What drives this process? I assume it is part of JES message handling 2. Is the line length before wrapping a message held in a parameter somewhere? 3. What causes some messages to use the #, and others to just wrap. For example, if I write a COBOL program with DISPLAY...UPON CONSOLE, the lines just wrap in the Syslog, with no ### identifier. Other jobs or STCs write messages like the above, with the continuation number. 4. Is there some doc I can point to for my colleague to understand this? We all know what it is, and most of us probably don't care how it works, but I figure that someone knows what this is called, how it is configured, and how it works for different messages. Thanks all! Don Don Johnson Broadcom donald.johnso...@broadcom.com | broadcom.com -- 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
Question on wrapped JESMSGLG messages
I have a peculiar question and hope the answer is easily found in this group. Looking at these highlighted values 08.17.38 JOB57837 DJMU2DF:DB01900I - MUF DJMU2DF,99,NO 08.17.38 JOB57837 DJMU2DF:DB01909E - * - ASTERISK 682 682 POINTS NEAR ERROR 08.05.17 JOB57048 IEC161I 056-084,CICSABCD,$$@ $$@,DFHLCD,,, 571 571 IEC161I OMY.CICS.DFHLCD,OMY.CICS.DFHLCD.DATA, 571 IEC161I ICF.ABCD.USERCAT I know that the number is a cross-reference for continued lines in Syslog and the user joblog, and I have never thought twice about it before. However, I have someone asking about this, and I realized that I don't really know how it works. My questions are: 1. What drives this process? I assume it is part of JES message handling 2. Is the line length before wrapping a message held in a parameter somewhere? 3. What causes some messages to use the #, and others to just wrap. For example, if I write a COBOL program with DISPLAY...UPON CONSOLE, the lines just wrap in the Syslog, with no ### identifier. Other jobs or STCs write messages like the above, with the continuation number. 4. Is there some doc I can point to for my colleague to understand this? We all know what it is, and most of us probably don't care how it works, but I figure that someone knows what this is called, how it is configured, and how it works for different messages. Thanks all! Don Don Johnson Broadcom donald.johnso...@broadcom.com | broadcom.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Activate SMS configuration in batch
W dniu 14.05.2020 o 12:43, Gadi Ben-Avi pisze: Hi, Does anyone know of a way to activate an SMS configuration in batch? I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a way that will wait until the activation is complete before continuing to the next step. We are running z/OS v2.2 What about // COMMAND ? -- 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.2020 r. wynosi 169.401.468 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.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RES: An older device query - still using??
Before launch IBM 3540 Diskette Unit (could write and read floppy 8 pol disks and connected to a /370 parallel channel) after recording diskettes using IBM 3741 (single operator station) or IBM 3742 (double operator station) was necessary to move data from them to a tape reel using IBM 3747 Converter Unit. Since diskettes and tape reel could be used a lot of times, this solution brings to customers a great economy. I remember to walk in an aisle aside a Data Entry room with more them 150 IBM 3742 stations in a big bank here in Brazil, they were one of pioneers to remove old IBM 0029, IBM 0059 and IBM 0129 machines from data entry process. IBM 3540 arises to eliminated one step (convert to tape reel) and could accelerate process to make data transcript from a bunch of different forms in data to supply information to data systems. Old good time of batch processing overnight. Carlos Bodra IBM zEnterprise Certified São Paulo – SP – Brazil -Mensagem original- De: IBM Mainframe Discussion List Em nome de Tony Thigpen Enviada em: quarta-feira, 13 de maio de 2020 23:38 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: Re: An older device query - still using?? The 3540 was the reader/punch that was to replace the card reader/punch system. Which it did at both my college (while I was there) and at my first job (where it replaced the 96 column card system) just before I got there. The 3740 and 3742 were the replacement for the card punch machine. They were highly programmable. You could set up programs where some characters "punched" as packed decimal and other characters were punched as display characters. It would also sum-check fields in a single record and automatically punch final "sums records". The 3540 had a AWSOMA: Optical Media AttachTOC that contained a VOL1 record and multiple HDR1 records which supported multiple files. It had tracks and records. I am fuzzy, but I think it supported different record lengths (set in the HDR1 for each file). I know you could punch both 80 and 96 (in separate files). The VTOC design was also used in the Optical Media Attach Feature, which was actually 'emulated' on the P360/P390 in the AWSOMA dirver. (All "facts" subject to dropped memory bits due to old age.) Tony Thigpen R.S. wrote on 5/13/20 6:59 PM: > I just checked bitsavers and found some information about 3540 > 1. Capacity - it depends. There were several types and subtypes, and > sub-subtypes of diskettes. Approximately 256kB to 1,2 MB, however 3540 > used only those low capacity. (details available on request) > 2. Feeding media - automatically, not manually. > 3. There were two types of 3540, single and double drive. > 4. The purpose was to deliver data from keypunch (wrong!) data entry > stations. At the times before CRT screens became popular. > > However still I have no idea about system support. How to write data on > diskette, how to read from diskette, how to recognize volume ID, etc. > No, I'm not going to use it, but I'm just curious. > -- 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: USS Open in SYSCALL ENV
I assume that you mean Unix syscall environment. The documentation is a bit confusing, because the syscall commands set RETVAL, which is the behavior associated with a function. Are you looking at RC or at RETVAL? could you show your code? Are you running from IRXJCL, TSO or a Unix shell? My guess is that you did not invoke your code from a Unix shell and that 0 was the first available file descriptor. If that is the case then you might want to open STDIN, STDOUT and STDERR at the beginning of your code. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Michael Babcock [bigironp...@gmail.com] Sent: Thursday, May 14, 2020 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: USS Open in SYSCALL ENV In the USS REXX SYSCALL environment, is it normal for a command such as: open /u/xx35/test, o_rdwr+o_creat+o_trunc, 755 To return a file descriptor of 0 (zero)? The reason I ask is that the subsequent write fails with RC 71 RSN 571011C Which basically says: file is not opened I thought fd 0 is normally STDIN. -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- 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: An older device query - still using??
On Thu, 14 May 2020 00:59:04 +0200, R.S. wrote: > >However still I have no idea about system support. How to write data on >diskette, how to read from diskette, how to recognize volume ID, etc. >No, I'm not going to use it, but I'm just curious. > I only used 3540 on a DOS/VSE system. They could be referenced on ASSGN statements // ASSGN SYSxxx,3540, and DLBL identified which fileid on the diskette. http://bitsavers.trailing-edge.com/pdf/ibm/370/DOS_VSE/SY33-8571-7_DOS_VSE_Handbook_Feb79.pdf MVS input support was only for instream input datasets like: IBM 3540 diskette volumes can contain associated data sets. Associated data setsare treated like in-stream data sets and are spooled in as SYSIN data sets. Theseassociated data sets are identified by coding a DSID parameter and, optionally, avolume serial on a DD * or DD DATA statement in the input stream: //ddname DD *,DSID=,VOLUME=SER=yy MVS output for sysout: Data sets are written on 3540 diskette volumes by coding: //ddname DD SYSOUT=(class,diskette-writer),DSID=id //ddname DD SYSOUT=(class,diskette-writer),DSID=(id,V) Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
USS Open in SYSCALL ENV
In the USS REXX SYSCALL environment, is it normal for a command such as: open /u/xx35/test, o_rdwr+o_creat+o_trunc, 755 To return a file descriptor of 0 (zero)? The reason I ask is that the subsequent write fails with RC 71 RSN 571011C Which basically says: file is not opened I thought fd 0 is normally STDIN. -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What crashing COBOL systems reveal about applications maintenance -- GCN
Hi Wayne! If you'd like to recompile that C code too - just drop us a note! Newer versions of Systems/C have better optimization too! - Dave Rivers - Wayne Bickerdike wrote: We're going through the COBOL 6 compile exercise, on a Z13. The only hiccups have been source control and the odd JCL error. One job fell over in a link edit because a module wasn't found. It's been nearly 15 years since I worked with this system but somehow I remembered this module. Turns out it's an object module that was compiled using a C compiler that we never licenced. At the time, I thought we might get the Dignus C compiler. It never happened. So all these years later we have a module, that does some primitive encryption, written in C, author unknown. Fortunately, it's only used in 3 programs. Not the fault of COBOL again. It's impressive that not much has been misplaced in over 7,000 source members and other pieces such as BMS maps. I'm keen to see how the new objects perform too. -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Activate SMS configuration in batch
Hi, Does anyone know of a way to activate an SMS configuration in batch? I know I can issue the SETSMS SCDS(xx) command in batch, but I am long for a way that will wait until the activation is complete before continuing to the next step. We are running z/OS v2.2 Thanks Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
