Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Paul Gilmartin
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

Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Seymour J Metz
> +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

Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Charles Mills
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:

Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Charles Mills
+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

Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Paul Gilmartin
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. >

Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Seymour J Metz
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

Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Paul Gilmartin
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

Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Seymour J Metz
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

Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Charles Mills
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

Re: REXX assistance

2020-05-24 Thread Sebastian Welton
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

Re: Opinions/experience on sharing catalogs outside plex

2020-05-24 Thread Jesse 1 Robinson
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

Re: Move volcat to non sms volume

2020-05-24 Thread Gadi Ben-Avi
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:

Re: Move volcat to non sms volume

2020-05-24 Thread Joe Monk
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

Move volcat to non sms volume

2020-05-24 Thread Gadi Ben-Avi
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

Re: Friday Follies/Why won't this work?/TSO Rant #387

2020-05-24 Thread Seymour J Metz
> 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