Re: Friday Follies/Why won't this work?/TSO Rant #387
On Sun, 24 May 2020 18:26:13 -0700, Charles Mills wrote:
>...
>+1 (What the H*** is gained by uppercasing a CART where the underlying
>service supports any 64-bit value? Don't over validate! This is the problem
>with various utilities that could handle UNIX files except that the utility
>"validates" the filename and rejects slashes or lowercase letters.)
>
Most conspicuous to me is the failure of "TSO ALLOCATE PATH('/dev/null')"
on various ISPF panel command lines.
And semantic more than semantic, the failure of SYSEXEC or
AMATERSE UNPACK SYSUT1 when allocated to UNIX directories
or files. It seems to be a gratuitous check on DSORG which can
be circumvented by pre-concatenating an empty Classic DSN.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Follies/Why won't this work?/TSO Rant #387
> +1 (What the H*** is gained by uppercasing a CART where the underlying > service supports any 64-bit value? Inertia? Blind adherence to poorly understood specifications. There are lots of pathlogies in large organizations that could explain it. Report it, and if it comes back BAD then submit an RFE. There is nothing in TSO that either requires the misbehavior or that requires the documentation of the misbehavior to be camouflaged. I've already submitted an RFC, but IMHO it's the code that should be changed. -- 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: Sunday, May 24, 2020 9:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 +1 (SUBMIT) +1 (Doc) +1 (What the H*** is gained by uppercasing a CART where the underlying service supports any 64-bit value? Don't over validate! This is the problem with various utilities that could handle UNIX files except that the utility "validates" the filename and rejects slashes or lowercase letters.) I've done my part on various RCF's but not so far on this one. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, May 24, 2020 5:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 Never mind case; when will SUBMIT recognize that 80 is not the only integer? Also, when TSO (sub)commands upper case their input, the documentation should say so in an obvious location as part of the (sub)command description. Finally, when a TSO (sub)command provides the facilities of a documented subroutine or assembler macro, it should not impose additional syntactic constraints or transformations beyond those documented for the underlying services. OTOH, people should RTFM and submit an RCF if they find TFM to be deficient. -- 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: Sunday, May 24, 2020 7:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 On Sun, 24 May 2020 14:26:51 -0700, Charles Mills wrote: > >'MyCart01' (as written, in camel-case) was my intended CART and it is a valid CART: a CART may have any 64-bit value. The problem was that the CONSOLE command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as to uppercase it the problem would have disappeared, but two wrongs don't make a right. > It's far overdue that interfaces quit forcing the limitations of the 029 keypunch on users. Decades ago, I learned that if I need upper case I press the SHIFT key; otherwise I should get what I type. It's fine for functions to be case insensitive, case sensitive, or monocase. It's wrong for upstream processes to second-guess -- they're too often wrong. And it was a design error for Binder to provide a CASE UPPER option. CASE MIXED, compatible with Linkage Editor, should always be in force. -- 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: Friday Follies/Why won't this work?/TSO Rant #387
Right! Let the service fail and then report its error. Don't introduce some new error to document and be learned. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, May 24, 2020 6:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 On Mon, 25 May 2020 00:53:04 +, Seymour J Metz wrote: >Never mind case; when will SUBMIT recognize that 80 is not the only integer? > >Also, when TSO (sub)commands upper case their input, the documentation should >say so in an obvious location as part of the (sub)command description. > >Finally, when a TSO (sub)command provides the facilities of a documented >subroutine or assembler macro, it should not impose additional syntactic >constraints or transformations beyond those documented for the underlying >services. > Further, when a user violates the documented restrictions of a subroutine or assembler macro (possibly by directly issuing an SVC), that service should fail and report the error. I think of such as trying to STOW "Fred.txt". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Follies/Why won't this work?/TSO Rant #387
+1 (SUBMIT) +1 (Doc) +1 (What the H*** is gained by uppercasing a CART where the underlying service supports any 64-bit value? Don't over validate! This is the problem with various utilities that could handle UNIX files except that the utility "validates" the filename and rejects slashes or lowercase letters.) I've done my part on various RCF's but not so far on this one. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, May 24, 2020 5:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 Never mind case; when will SUBMIT recognize that 80 is not the only integer? Also, when TSO (sub)commands upper case their input, the documentation should say so in an obvious location as part of the (sub)command description. Finally, when a TSO (sub)command provides the facilities of a documented subroutine or assembler macro, it should not impose additional syntactic constraints or transformations beyond those documented for the underlying services. OTOH, people should RTFM and submit an RCF if they find TFM to be deficient. -- 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: Sunday, May 24, 2020 7:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 On Sun, 24 May 2020 14:26:51 -0700, Charles Mills wrote: > >'MyCart01' (as written, in camel-case) was my intended CART and it is a valid CART: a CART may have any 64-bit value. The problem was that the CONSOLE command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as to uppercase it the problem would have disappeared, but two wrongs don't make a right. > It's far overdue that interfaces quit forcing the limitations of the 029 keypunch on users. Decades ago, I learned that if I need upper case I press the SHIFT key; otherwise I should get what I type. It's fine for functions to be case insensitive, case sensitive, or monocase. It's wrong for upstream processes to second-guess -- they're too often wrong. And it was a design error for Binder to provide a CASE UPPER option. CASE MIXED, compatible with Linkage Editor, should always be in force. -- 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: Friday Follies/Why won't this work?/TSO Rant #387
On Mon, 25 May 2020 00:53:04 +, Seymour J Metz wrote: >Never mind case; when will SUBMIT recognize that 80 is not the only integer? > >Also, when TSO (sub)commands upper case their input, the documentation should >say so in an obvious location as part of the (sub)command description. > >Finally, when a TSO (sub)command provides the facilities of a documented >subroutine or assembler macro, it should not impose additional syntactic >constraints or transformations beyond those documented for the underlying >services. > Further, when a user violates the documented restrictions of a subroutine or assembler macro (possibly by directly issuing an SVC), that service should fail and report the error. I think of such as trying to STOW "Fred.txt". >OTOH, people should RTFM and submit an RCF if they find TFM to be deficient. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Follies/Why won't this work?/TSO Rant #387
Never mind case; when will SUBMIT recognize that 80 is not the only integer? Also, when TSO (sub)commands upper case their input, the documentation should say so in an obvious location as part of the (sub)command description. Finally, when a TSO (sub)command provides the facilities of a documented subroutine or assembler macro, it should not impose additional syntactic constraints or transformations beyond those documented for the underlying services. OTOH, people should RTFM and submit an RCF if they find TFM to be deficient. -- 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: Sunday, May 24, 2020 7:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 On Sun, 24 May 2020 14:26:51 -0700, Charles Mills wrote: > >'MyCart01' (as written, in camel-case) was my intended CART and it is a valid >CART: a CART may have any 64-bit value. The problem was that the CONSOLE >command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as >to uppercase it the problem would have disappeared, but two wrongs don't make >a right. > It's far overdue that interfaces quit forcing the limitations of the 029 keypunch on users. Decades ago, I learned that if I need upper case I press the SHIFT key; otherwise I should get what I type. It's fine for functions to be case insensitive, case sensitive, or monocase. It's wrong for upstream processes to second-guess -- they're too often wrong. And it was a design error for Binder to provide a CASE UPPER option. CASE MIXED, compatible with Linkage Editor, should always be in force. -- 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: Friday Follies/Why won't this work?/TSO Rant #387
On Sun, 24 May 2020 14:26:51 -0700, Charles Mills wrote: > >'MyCart01' (as written, in camel-case) was my intended CART and it is a valid >CART: a CART may have any 64-bit value. The problem was that the CONSOLE >command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as >to uppercase it the problem would have disappeared, but two wrongs don't make >a right. > It's far overdue that interfaces quit forcing the limitations of the 029 keypunch on users. Decades ago, I learned that if I need upper case I press the SHIFT key; otherwise I should get what I type. It's fine for functions to be case insensitive, case sensitive, or monocase. It's wrong for upstream processes to second-guess -- they're too often wrong. And it was a design error for Binder to provide a CASE UPPER option. CASE MIXED, compatible with Linkage Editor, should always be in force. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Follies/Why won't this work?/TSO Rant #387
No, the problem is you didn't adhere to the interface, possibly because the relevant statement is not (RCF submitted*) in the obvious location. CONSOLE is not the only case where you need to know the case behavior of the command. I never said that you should uppercase everything, only that you should use the *correct* case for the task at hand, and that I've seen a lot of errors stemming from the failure to do so. You are incorrect in your fantasy that you are a telepath. You are imputing to me beliefs and impressions that I have never held and claims that I have never made. Please rebut claims that people actually made, not claims you invented on the spot. As for the subject line, it's wrongheaded. It's not some abstract TSO in the sky that uppercased the CART, it's, e.g., the CONSOLE command, the CART subcommand. I've been using TSO commands with mixed case operands since before you could spell TSO, and they worked just fine. * You could try to submit a problem report, but I suspect that it will be closed as BAD. -- 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: Sunday, May 24, 2020 5:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 The problem was NOT that Rexx (or my coding style) failed to uppercase an operand; the problem was that TSO did. Note my subject line: a rant about TSO. 'MyCart01' (as written, in camel-case) was my intended CART and it is a valid CART: a CART may have any 64-bit value. The problem was that the CONSOLE command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as to uppercase it the problem would have disappeared, but two wrongs don't make a right. Had Rexx or my coding style inadvertently uppercased my intended CART it would simply have created a false impression of what constitutes a valid CART. Note what the first almost correct answerer posted: "Your problem is caused by using lower case characters in your CART parameter value, the value of variable MyCart. If you used all upper case, or all numerics, it would work fine. That's not documented anywhere that I've thus far been able to find." He is incorrect in his impression of what constitutes a valid CART, and his wrong impression of CART validity would be reinforced if Rexx or my coding style "corrected" my camel-case CART. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Saturday, May 23, 2020 11:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 > You seem stuck on this capitalization thing. You seem to forget that this thread started on a capitalization issue. You also seem to assume that my alleged fixation affects the way others code. You might note that of the three error issues I listed, capitalization was last - why did you single it out? > I’ve never had such a problem, K3wl. What about code written by others. -- 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: Friday Follies/Why won't this work?/TSO Rant #387
The problem was NOT that Rexx (or my coding style) failed to uppercase an operand; the problem was that TSO did. Note my subject line: a rant about TSO. 'MyCart01' (as written, in camel-case) was my intended CART and it is a valid CART: a CART may have any 64-bit value. The problem was that the CONSOLE command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as to uppercase it the problem would have disappeared, but two wrongs don't make a right. Had Rexx or my coding style inadvertently uppercased my intended CART it would simply have created a false impression of what constitutes a valid CART. Note what the first almost correct answerer posted: "Your problem is caused by using lower case characters in your CART parameter value, the value of variable MyCart. If you used all upper case, or all numerics, it would work fine. That's not documented anywhere that I've thus far been able to find." He is incorrect in his impression of what constitutes a valid CART, and his wrong impression of CART validity would be reinforced if Rexx or my coding style "corrected" my camel-case CART. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Saturday, May 23, 2020 11:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 > You seem stuck on this capitalization thing. You seem to forget that this thread started on a capitalization issue. You also seem to assume that my alleged fixation affects the way others code. You might note that of the three error issues I listed, capitalization was last - why did you single it out? > I’ve never had such a problem, K3wl. What about code written by others. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
I run some IDCAMS processing under NetView for collecting certain data and have
never seen such a problem. The following are some old examples of the code and
this runs a LISTCAT and puts everything into a stem:
Do i = 1 To dsn.0
lc.1 = ' LISTCAT -' /* LISTCAT SYSIN statements */
lc.2 = 'LVL('dsn.i') -'
lc.3 = 'NONVSAM -'
lc.4 = 'VOLUME '
lc.0 = 4
'PIPE STEM lc.' , /* Run a PIPE with LISTCAT */
'| COLLECT' ,
'| NETV MOE DSIVSMX IDCAMS' ,
'| STEM lvl. APPEND'
End
The following runs DCOLLECT and writes the output to a dataset:
'ALLOCATE DATASET('"'"outpdsn"'"') FILE(OUTDS) OLD'
dc.1 = ' DCOLLECT -'
dc.2 = 'OFILE(OUTDS) -'
dc.3 = 'NODATAINFO -'
dc.4 = 'VOLUME('dasd_type')'
dc.0 = 4
'PIPE STEM dc.' ,
'| COLLECT' ,
'| NETV MOE DSIVSMX IDCAMS' ,
'| STEM vs.'
'FREE DATASET('"'"outpdsn"'"') NOHOLD'
To then read that dataset, I just use the QSAM stage:
'PIPE QSAM (DSN)' outpdsn ,
'| STEM uv.'
Do i = 1 To uv.0
Hopefully this gives some ideas on what to do. I don't use EXECIO in NetView
but the QSAM stage to read datasets so that might be causing your problem.
Sebastian
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Opinions/experience on sharing catalogs outside plex
Until recently, we shared a catalog not only across sysplexes but between data centers. All because of tape. We had STK virtual tape (in both data centers) supported by MIA (Multi Image Allocation). These products require control data sets shared among all exploiting systems. We could have managed with uncataloged data sets, but that was deemed riskier in the long run than a shared catalog. The only entries in the catalog were for tape management data sets. We never had a catastrophe. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, April 20, 2020 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Opinions/experience on sharing catalogs outside plex CAUTION EXTERNAL EMAIL Well, it is not good idea, but sometimes even such idea is better than nothing. What's important the risk covers THIS catalog only, not whole world. And yes, this catalog and shared datasets should be shared without "sysplex features" like changes is serialization. RESERVE should be used here or CA-MIM should be used, but the last one is add-on tool. BTW: BCS can be defined with SHR(3 4) or SHR(3 3). For this case it has to be SHR(3 4). AFAIK it is alterable. Again: small activity is your friend here. Small number of datasets cataloged in the BCS is good here. Potential problems with the BCS will not affect other BCSes. I use it for years (with limited activity). Mostly PS files and some VSAM. No problems observed. Caution: PDSE *will* break despite of way how catalog is shared. No help from CA-MIM, AFAIK. Observed many times educated many guys who used PDSE for sharing. -- Radoslaw Skorupka Lodz, Poland W dniu 20.04.2020 o 14:45, Allan Staller pisze: > Yes, it can be done. I reiterate, IMO, this is most likely not a good idea. > In order to accomplish this safely, you also need to regress GRS to pre-GRS > functionality. > Everything affecting this catalog must be handled w/Reserve/Release, > and not normal processing VSAM Sharoptions for the catalog need to be > changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or was > it 4,3?). > This option tells z/OS that the user is responsible for Catalog > seriailization. > SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be > excluded from GRS processing. > > In my case that led to various deadly embraces that usually led to manual > intervention. > > My $0.02 USD on this is: Why point the shotgun at your foot? > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: Monday, April 20, 2020 3:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Opinions/experience on sharing catalogs outside plex > > [CAUTION: This Email is from outside the Organization. Do not click > links or open attachments unless you trust the sender.] > > W dniu 09.04.2020 o 02:11, Rob Schramm pisze: >> I am considering sharing some usercats outside of a sysplex. What I >> can find is that sysiggv2 must be kept as a reserve to do so. >> >> Looking for others that have had to do this. >> >> One question I had was, what happens on a ispf 3.4 when the data set >> is part of the catalog but exists in another system? Ief238d? > My €0.02 > > 1. You can share catalogs between sysplexes. Note: we mean BCS, which is > usually called catalog. > 2. The less activity on the BCS the better. > 3. The above means: > 3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for that. > 3.2. It is not bad idea to have multiple "small" shared BCSes. > 4. You cannot use any sophisticated catalog sharing features like RLS or ECS. > > Regarding you last question: I understand it as you have entry in the BCS, > but the dataset reside on volume which is not share, that mean it is > unavailable for one system. It's nothing exotic. It's like orphan catalog > entry, which sometimes may happen even without BCS sharing (usually as result > of human error). > However that also means the sharing is not done correctly. The best scenario > is when all datasets cataloged in shared BCS reside on volumes which are also > shared. Preferably the BCS is also on the volume from that group. > Keep it simple. > > -- > Radoslaw Skorupka > Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Move volcat to non sms volume
Thanks, but that doesn't work. What did work was allocating the volcat on the volume I wanted to use. and then using the intoempty paramters in the import. Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Sunday, May 24, 2020 12:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Move volcat to non sms volume By using the VOLUMES keyword on the IMPORT, and specifying a NON-SMS managed volume... https://www.ibm.com/support/pages/how-move-volcat-new-volume Joe On Sun, May 24, 2020 at 2:30 AM Gadi Ben-Avi wrote: > Hi, > Our volcat (SYS1.VOLCAT.VGENERAL) was allocated on an SMS managed volume. > We would like to move it to a Non SMS managed volume. > > The way I found was to export it and then import. > How do I tell IMPORT to allocate it on a non SMS managed volume, and > not on the storage class it was exported from? > > 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 Email secured by Check Point -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Move volcat to non sms volume
By using the VOLUMES keyword on the IMPORT, and specifying a NON-SMS managed volume... https://www.ibm.com/support/pages/how-move-volcat-new-volume Joe On Sun, May 24, 2020 at 2:30 AM Gadi Ben-Avi wrote: > Hi, > Our volcat (SYS1.VOLCAT.VGENERAL) was allocated on an SMS managed volume. > We would like to move it to a Non SMS managed volume. > > The way I found was to export it and then import. > How do I tell IMPORT to allocate it on a non SMS managed volume, and not > on the storage class it was exported from? > > 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
Move volcat to non sms volume
Hi, Our volcat (SYS1.VOLCAT.VGENERAL) was allocated on an SMS managed volume. We would like to move it to a Non SMS managed volume. The way I found was to export it and then import. How do I tell IMPORT to allocate it on a non SMS managed volume, and not on the storage class it was exported from? Thanks Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Follies/Why won't this work?/TSO Rant #387
> You seem stuck on this capitalization thing. You seem to forget that this thread started on a capitalization issue. You also seem to assume that my alleged fixation affects the way others code. You might note that of the three error issues I listed, capitalization was last - why did you single it out? > I’ve never had such a problem, K3wl. What about code written by others. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Phil Smith III [li...@akphs.com] Sent: Sunday, May 24, 2020 1:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387 Metz wrote: >Well, I've only been using REXX for 35 years. The problems that I have seen >from not quoting words have been few and far between, not nearly as many as, >e.g., problems related to continuation, omitting a period in a stem, incorrect >capitalization in a string literal. You seem stuck on this capitalization thing. I’ve never had such a problem, perhaps because I capitalize literals as needed. I’d never assume that mixed case in a literal is OK unless it’s deliberate, no matter the environment. Part of my Rexx Programming Style presentation, given at SHARE many times! I have seen nasty bugs from not quoting literals, not to mention the performance hit. -- 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
