Re: Why are TSO IDs limited to 7 characters
On 5 November 2010 21:58, John McKown wrote: > I really wonder how hard this would be. But I don't know everywhere the > TSO id is stored. In the few places that I have found, it seems that the > ID field is defined as CL7, but there always seems to be a FL1 field > next to it to store the length. Seems to me that the length field could > be used to store the 8th character for 8 character IDs. Since a RACF id > can only have A-Z 0-9 $...@# as a valid character. And the lowest hex value > of these is the $ at x'5B', then if the "length" field is >x'07', it > must be the last character of the ID and the length of the ID must be 8. > If it is <= x'07', then the field still contains the ID length. Granted, > clumsy to implement, but seems like it will fit in the number of bytes > generally available. Sure, but all existing software that trusts that length byte is going to fail, quite possibly with Very Bad consequences. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
REDBOOKS Question
I have forgotten the answer to this question long ago and I am not coming up with any answer to my question to myself.I will pose it to the group and see if anyone on here knows the answer.I am trying to remember how IBM handles it if there is an error (or poorly written or whatever error) happens with REDBOOKS. Are they quietly updated (and if so) is there a new dash number or is there a completely new number assigned or how does IBM handle updates to any REDBOOKS? I know there are errors as long time ago (30+ years) I used to see them with TNL's (we all remember those right?) but I do not remember how IBM handles them currently. Anyone? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
I am coming late into this thread and did not see the original post.So I will pipe up and then let others comment. Back in MVT days UADS (technically it still is) UADS was a PDS and the member name in UADS was limited to 8 characters. In UADS there was a variable length section(s) in each section there was (IIRC) room for a 44(?) character accounting code also password and region size and procedure name. This was OK except sometimes when you added another accounting field, proc name and region size and password the entry would grow. UADS had a blocksize max of 800 (IIRC) so when the blocksize went over 800 the system would create another userid and add a "1" to the end.so if you id was 7 chracters the 8th character was reserved for the rest of the password/accounting etc info. It was clever (I thought). We were lucky as all of our ID's at the time aere 3 or 5 caracters (with 1 exception IIRC). Ed --- On Sat, 11/6/10, J R wrote: From: J R Subject: Re: Why are TSO IDs limited to 7 characters To: IBM-MAIN@bama.ua.edu Date: Saturday, November 6, 2010, 1:29 PM No. I have no problem with TSO EDIT. > Date: Sat, 6 Nov 2010 14:23:01 -0400 > From: ibm...@woodsway.com > Subject: Re: Why are TSO IDs limited to 7 characters > To: IBM-MAIN@bama.ua.edu > > On Friday 05 November 2010 16:46, Shmuel Metz (Seymour J.) wrote: > > In , > > on 11/05/2010 > > > > at 09:46 AM, "Roach, Dennis (N-GHG)" said: > > > > >Try the TSO EDIT command from ready some time. > > > > I have. > > > > >Make you like vi. > > > > No. > > Yes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IDCAMS ALTER and GDGs - From A(0) to B(+1) - Relative Generations
Scott Barry pisze:
If a tape dataset name is 17 characters or longer (and the last 17
characters do not change), I believe that it can be renamed, using a DEFINE
NVSAM command (with DEVTYPE, VOLUMES and optionally FSEQN), along with the
requisite DELETE '' NOSCRATCH command. At least with CA-1, there are
TMC update utilities TMSUPDTE and TMSUDSNB ("restricted use" though), as
well, to consider using with this activity, where any DSN length is a
candidate for change.
Well, in this case last 17 characters do contain GoooVoo.
All the commands above do change catalog and/or TMS entry, but not
physical DSN recorded on tape in the HDR label. Inconsistence between
label and JCL DD could lead to x13 abend (813 AFAIR). Maybe CA-1 could
help here, but I'm not sure, guess that no.
IMHO the solution would be:
a) Leave it as it is.
b) Change the process. Eliminate the need. Maybe it's much simpler than
tweaking with dsnames.
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 025237
NIP: 526-021-50-88
Wedug stanu na dzie 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci
wpacony) wynosi 168.248.328 zotych.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rexx question - Dynamic generation of variables?
On Sat, 2010-11-06 at 18:26 -0500, Paul Gilmartin wrote: > On Sat, 6 Nov 2010 16:58:47 -0500, John McKown wrote: > > > >I think of a REXX stem variable the same way that I do an Perl hash. Or > >more like a value associated with a "key" where the key is an arbitrary > >value. And a stem.var1.var2 is like a hash of a hash in Perl. > > > If I understand what you mean by "hash of a hash", I believe not. > As I posted yesterday: > > Beware the pitfall. If: > > W = 'a.b' > X = 'c' > Y = 'a' > Z = 'b.c' > > then Stem.W.X and Stem.Y.Z refer to the same member of the > compound, regardless that none of the subscripts are equal. > > Multiple subscripts are flattened, in a possibly degenerate manner. > > -- gil > > -- Ouch. I didn't realize that. I must have missed some of the previous posts. -- John McKown Maranatha! <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IDCAMS ALTER and GDGs - From A(0) to B(+1) - Relative Generations
At 09:53 -0500 on 11/06/2010, Scott Barry wrote about Re: IDCAMS
ALTER and GDGs - From A(0) to B(+1) - Relative G:
If a tape dataset name is 17 characters or longer (and the last 17
characters do not change), I believe that it can be renamed, using a DEFINE
NVSAM command (with DEVTYPE, VOLUMES and optionally FSEQN), along with the
requisite DELETE '' NOSCRATCH command. At least with CA-1, there are
TMC update utilities TMSUPDTE and TMSUDSNB ("restricted use" though), as
well, to consider using with this activity, where any DSN length is a
candidate for change.
Scott Barry
SBBWorks, Inc.
Interestingly the fact that only the LAST 17 characters of a 18-44
character dataset name are stored in a TAPE HDR1/EOF1/EOV1 label
allows the dataset to be renamed and still be acceptable so long as
the last 17 remain constant and the 1-27 character prefix is changed.
For GDGs, the .GVyy is stored as the last 9 characters leaving
only 8 characters of the actual name for comparing to the supplied
18-44 character DSN. Since the Gxxx and Vyy are replicated as
separate fields in the labels, IN THEORY, for 18-27 character GDG
names the name could fully be stored in the labels by storing the
1-17 character GDG Base Name in the DSN area and the G and Vyy
values in their dedicated fields thus closing this loophole for under
26 character long GDG Dataset Names stored on Tape.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
On 11/6/2010 12:17 PM, Paul Gilmartin wrote: On Sat, 6 Nov 2010 14:27:26 -0400, J R wrote: Good point. However, update-in-place really only *need* be done during the user's session to record profile changes, etc. Extending the member should only be necessary when the ACCOUNT command is adding segments, in which case it shoul be opened for output and recreate the entire member. ... which leaves unused space in the PDS. If you do this enough times you run out. Then what do you do? This is exactly how ISPF profiles work. They place PAD records (the actual characters P-A-D) at the end of the member to leave room for expansion. They update the member in place whenever possible. When not possible, they write a new member with a new PAD area. Standard PDS processing applies. If the library gets full, it allocates new extents. When no more extents exist, a compress is necessary. In practice, with this design philosophy the compress is almost never necessary. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rexx question - Dynamic generation of variables?
On Sat, 6 Nov 2010 16:58:47 -0500, John McKown wrote: > >I think of a REXX stem variable the same way that I do an Perl hash. Or >more like a value associated with a "key" where the key is an arbitrary >value. And a stem.var1.var2 is like a hash of a hash in Perl. > If I understand what you mean by "hash of a hash", I believe not. As I posted yesterday: Beware the pitfall. If: W = 'a.b' X = 'c' Y = 'a' Z = 'b.c' then Stem.W.X and Stem.Y.Z refer to the same member of the compound, regardless that none of the subscripts are equal. Multiple subscripts are flattened, in a possibly degenerate manner. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rexx question - Dynamic generation of variables?
On Sat, 2010-11-06 at 16:04 -0500, Joel C. Ewing wrote: > I believe that REXX only directly supports one of those two mechanisms, > namely the symbol table lookup and not true indexed arrays. Although > one may use in a REXX program "symbol.ix", where ix in that particular > program is always a positive numeric integer, I would think this only > gives the illusion of an indexed array and not the reality, since an > interpreter like REXX cannot assume that later stem arguments will > continue to be numeric, and also "symbol.1" is distinct from "symbol.001". > > The distinction that John draws is not really related to the number of > dimensions involved or to the concept that a multi-variate function may > be re-conceptualized as a single-variate function whose domain is a set > involving a product of the original domains. The distinction made is > rather one of whether the original variable domains consist of > consecutive integer values or not. If so, the process of locating and > retrieving values can be done much more cheaply by offset calculation. > > Indexed lookup is definitely more efficient, and simpler techniques can > be used to implement it -- and this may affect the contexts in which > each approach is best used or even practical. But, functionally, > indexed arrays are just a special subset of symbol table lookup: where > the symbol values (consecutive integers) are so predictable they need > not be stored, the hashing function to locate an entry is the simple > offset calculation previously indicated, and collisions with conflicting > symbols are known to be impossible. > Joel C Ewing I think of a REXX stem variable the same way that I do an Perl hash. Or more like a value associated with a "key" where the key is an arbitrary value. And a stem.var1.var2 is like a hash of a hash in Perl. -- John McKown Maranatha! <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rexx question - Dynamic generation of variables?
I believe that REXX only directly supports one of those two mechanisms, namely the symbol table lookup and not true indexed arrays. Although one may use in a REXX program "symbol.ix", where ix in that particular program is always a positive numeric integer, I would think this only gives the illusion of an indexed array and not the reality, since an interpreter like REXX cannot assume that later stem arguments will continue to be numeric, and also "symbol.1" is distinct from "symbol.001". The distinction that John draws is not really related to the number of dimensions involved or to the concept that a multi-variate function may be re-conceptualized as a single-variate function whose domain is a set involving a product of the original domains. The distinction made is rather one of whether the original variable domains consist of consecutive integer values or not. If so, the process of locating and retrieving values can be done much more cheaply by offset calculation. Indexed lookup is definitely more efficient, and simpler techniques can be used to implement it -- and this may affect the contexts in which each approach is best used or even practical. But, functionally, indexed arrays are just a special subset of symbol table lookup: where the symbol values (consecutive integers) are so predictable they need not be stored, the hashing function to locate an entry is the simple offset calculation previously indicated, and collisions with conflicting symbols are known to be impossible. Joel C Ewing On 11/06/2010 02:06 PM, john gilmore wrote: Joel Ewing wrote: | This technique in effect maps any number of dimensions to a single dimension. and there is an important functional sense in which his statement is correct; but 1) it confounds two very different mechanisms, 2) it is not a scheme specific to REXX, and 3) these two mechanisms have their own distinct, non-overlapping uses. Let us look first at subscripting, specifically at a one-dimensional, eight-element single-byte array having what I shall call the identifier x, |0|1|2|3|4|5|6|7| Suppose now that we wish to access element i, 0<= i<= 7 of x. If the address of this array is addr(x) then the address of its i-th element is just> addr(x) + i. If now we consider another, two-dimensional, 2 x 4, eight-element single-byte array having the identifier y,> |0,0|0,1|0,2|0,3|1,0|1,1|1,2|1,3|> the address of its element having the subscripts i, j is just addr(y) + j + (i - 1)4 Here eight bytes of storage can be viewed as a one-dimensional array, as a two-dimensional one, or, on occasion, as both. The location of an element of a one-, two-, or n-dimensional array is determined arithmetically. (For simplicity I have made these elements single-byte ones that are stored in zero-origin, row-major sequence. Some arrays are one-origin ones; most have elements more than a single byte in length, and some FORTRAN dialects still store arrays in column-major order; but these differences are trivial.) What is important is that subscripting uses numeric function. Its argumet is a set of one or more subscripts and its value is an address. All subscripting schemes are devices for viewing a one-dimensional sequence of storage locations as a multidimensional one. Historically, identifiers or variable names were specified at program-writing time, but they can also be created at program-execution time. One needs a table of identifiers--It is/was often called a symbol table--and a convention for specifying/identifying the value of an identifier. In the IBM HLASM macro language, for example, ordinary set symbols have names like counter,&switch, or&abort that are given to them at program-writing time. They can also be created later, and these created set symbols are distinguished from ordinary set symbols using an extra set of parentheses. Thus |&name0setc'gubbins' --set-symbol identifier |gblc&(&name0) --created set symbol Encoumntering these statements, the HLASM macro processor loks in its symbol table for the identifier 'gubbins'. If it finds that identifier, its value is used. If not a created global set symbol is added to the appropriate symbol table. We can do much more interesting things too. Consider |&name1setc 'name0'.'&sex'.'&age'| gblc&(&name1) where&sex is always either 'M' or 'F' and&age is always one of '000', '001', '002', . . . , '999'. If then on some occasion&name1 has the value 'gubbinsM024' we ca view the statement |&name1 seta&(&name1)+1 as incrementing the count of 24-year-old males in some population. In practical terms this is much is scheme is very similar to one that uses a 2 x 1000 array, but the mechanism used to implement it is very different: ituses not subscripting but a large number of scalar identifiers that have an internal, decodable structure like that of a part nu
Re: Tivoli Storage Manager for z/OS (Functionally Stablized & Impending Demise)
Elaborating on Sam's response below, users of TSM for z/OS users may well be lamenting IBM's decision and continue to maintain a strong belief in the strengths of the mainframe as a backup server by being able to exploit z/OS's strengths of job scheduling, tape management and system security for the backing up of Open Systems data. As Sam has mentioned, users wanting to continue using the mainframe as a backup server because of its inherent strengths and stability should take a look at Innovation Data Processing's family of FDR/UPSTREAM solutions especially if running Linux on System z. There are many user success stories around and perhaps some of those users might respond to this thread. Sites with either IBM DS8700/DS8800 storage systems or EMC's SYMMETRIX/V-MAX systems, can also enjoy high-speed LAN-free backups using a FICON connection achievable with UPSTREAM/SOS. Furthermore, IBM recently released its Distributed Data Backup (DDB) for the DS8700 platform which is fully exploited by USPTREAM/SOS. Check the following links: http://www.innovationdp.fdr.com/products/upstream/ http://www.innovationdp.fdr.com/products/fdrsos/ Stephen Mednick Computer Supervisory Services Sydney, Australia Asia/Pacific representatives for Innovation Data Processing, Inc. Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Knutson, Sam Sent: Sunday, 7 November 2010 1:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Tivoli Storage Manager for z/OS (Functionally Stablized & Impending Demise) If IBM cannot or will not support z/OS in this roll there are good third party software vendors who do like Innovation. This will preserve your investment in z/OS and maintain the z/OS qualities of service and economies of scale you have today. http://www.fdr.com/products/upstream/index.cfm http://www.fdr.com/products/upstreamunix/ http://www.fdr.com/index.cfm Best Regards, Sam Knutson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tivoli Storage Manager for z/OS (Functionally Stablized & Impending Demise)
I can't believe only 4 licenses for TSM. I'll check to see of there is something new coming out. New guy on Tivoli team --Original Message-- From: Edward Jaffe Sender: IBM Mainframe Discussion List To: IBM-MAIN@bama.ua.edu ReplyTo: IBM Mainframe Discussion List Subject: Re: Tivoli Storage Manager for z/OS (Functionally Stablized & Impending Demise) Sent: Nov 6, 2010 5:41 AM On 11/5/2010 5:38 AM, Jim Marshall wrote: > Question - 1: > > "SO" I would like to know who are the other four people who had a similar idea > about using TSM for z/OS, to be the data backup place in order to leverage all > the good things z/OS has to offer. I guess we're one of the other four. TSM for z/OS works great for us. It's hooked into our mainframe-based "cron" facilities, uses large DASD EAVs, uses the same tapes and drives that HSM uses--which get moved by RMM to the same off-site locations, etc. I really don't want to try to come up with an alternate PC and zFS file backup strategy... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html nor...@desertwiz.biz Sent from my Verizon Wireless BlackBerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Rexx quest ion - Dyna mic genera tion of va riables?
In my previous post . . . have names like counter should have been . . . have names like &counter John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
On Sat, 6 Nov 2010 14:27:26 -0400, J R wrote: >Good point. However, update-in-place really only *need* be done during the >user's session to record profile changes, etc. > >Extending the member should only be necessary when the ACCOUNT command is >adding segments, in which case it shoul be opened for output and recreate the >entire member. > ... which leaves unused space in the PDS. If you do this enough times you run out. Then what do you do? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rexx question - Dynamic generation of variables?
Joel Ewing wrote: | This technique in effect maps any number of dimensions to a single dimension. and there is an important functional sense in which his statement is correct; but 1) it confounds two very different mechanisms, 2) it is not a scheme specific to REXX, and 3) these two mechanisms have their own distinct, non-overlapping uses. Let us look first at subscripting, specifically at a one-dimensional, eight-element single-byte array having what I shall call the identifier x, |0|1|2|3|4|5|6|7| Suppose now that we wish to access element i, 0 <= i <= 7 of x. If the address of this array is addr(x) then the address of its i-th element is just addr(x) + i. If now we consider another, two-dimensional, 2 x 4, eight-element single-byte array having the identifier y, |0,0|0,1|0,2|0,3|1,0|1,1|1,2|1,3| the address of its element having the subscripts i, j is just addr(y) + j + (i - 1)4 Here eight bytes of storage can be viewed as a one-dimensional array, as a two-dimensional one, or, on occasion, as both. The location of an element of a one-, two-, or n-dimensional array is determined arithmetically. (For simplicity I have made these elements single-byte ones that are stored in zero-origin, row-major sequence. Some arrays are one-origin ones; most have elements more than a single byte in length, and some FORTRAN dialects still store arrays in column-major order; but these differences are trivial.) What is important is that subscripting uses numeric function. Its argumet is a set of one or more subscripts and its value is an address. All subscripting schemes are devices for viewing a one-dimensional sequence of storage locations as a multidimensional one. Historically, identifiers or variable names were specified at program-writing time, but they can also be created at program-execution time. One needs a table of identifiers--It is/was often called a symbol table--and a convention for specifying/identifying the value of an identifier. In the IBM HLASM macro language, for example, ordinary set symbols have names like counter, &switch, or &abort that are given to them at program-writing time. They can also be created later, and these created set symbols are distinguished from ordinary set symbols using an extra set of parentheses. Thus |&name0setc'gubbins' --set-symbol identifier |gblc&(&name0) --created set symbol Encoumntering these statements, the HLASM macro processor loks in its symbol table for the identifier 'gubbins'. If it finds that identifier, its value is used. If not a created global set symbol is added to the appropriate symbol table. We can do much more interesting things too. Consider |&name1setc 'name0'.'&sex'.'&age'| gblc &(&name1) where &sex is always either 'M' or 'F' and &age is always one of '000', '001', '002', . . . , '999'. If then on some occasion &name1 has the value 'gubbinsM024' we ca view the statement |&name1 seta &(&name1)+1 as incrementing the count of 24-year-old males in some population. In practical terms this is much is scheme is very similar to one that uses a 2 x 1000 array, but the mechanism used to implement it is very different: ituses not subscripting but a large number of scalar identifiers that have an internal, decodable structure like that of a part number, insdurance-policy number or savings-account number, here some or all of gubbinsF000, gubbinsF001, . . . , gubbinsF999, gubbinsM000, gubbinsM001, . . . , gubbinsM999. Identifier-construction schemes like these are slower, much slower, than arithmetic subscripting; but if a table is sparsely populated, i.e., if only a few of the identifiers that a particular sceme makes possible are in fact used, they can be very useful. They have another important use in both the HLASM and REXX. They can be used to make data 'reentrant' in a Pickwickian but important sense. In certain HLASM table-generation macros, for example, I accumulate information in sets of global set symbol of the form |&valueid setc '&macname'.'&tabname'.'' | gblc &(&valueid)(1) and the use of this scheme permits two, three, or n different tables of the same sort but having different tabname= values to be assembled concurrently: the data for table alpha are distinguishable and distinguished from the data for table delta because 'alpha' and 'delta' appear as positional substrings in the different, non-overlapping identifiers of their data.Table-generation macros that use this scheme are reentrant in much the same sense in which procedures trhat use different blocks of automatic storage are reentrant. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to
Re: Why are TSO IDs limited to 7 characters
No. I have no problem with TSO EDIT. > Date: Sat, 6 Nov 2010 14:23:01 -0400 > From: ibm...@woodsway.com > Subject: Re: Why are TSO IDs limited to 7 characters > To: IBM-MAIN@bama.ua.edu > > On Friday 05 November 2010 16:46, Shmuel Metz (Seymour J.) wrote: > > In , > > on 11/05/2010 > > > > at 09:46 AM, "Roach, Dennis (N-GHG)" said: > > > > >Try the TSO EDIT command from ready some time. > > > > I have. > > > > >Make you like vi. > > > > No. > > Yes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
Good point. However, update-in-place really only *need* be done during the user's session to record profile changes, etc. Extending the member should only be necessary when the ACCOUNT command is adding segments, in which case it shoul be opened for output and recreate the entire member. > Date: Sat, 6 Nov 2010 10:45:08 -0500 > From: paulgboul...@aim.com > Subject: Re: Why are TSO IDs limited to 7 characters > To: IBM-MAIN@bama.ua.edu > > On Sat, 6 Nov 2010 11:06:09 -0400, J R wrote: > > >I'm not sure I buy this highly speculative explanation. > > > >There's a big difference between not allowing multiple blocks per member and > >not considering second blocks to be necessary. Furthermore, to "solve" the > >problem by introducing multiple members per userid, rather than multiple > >blocks per member, defies credibility. > > > I'm highly speculating about the possibility of update-in-place. If > UADS management employs update-in-place, the only way to extend a > member is to introduce an overflow member. > > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
On Friday 05 November 2010 16:46, Shmuel Metz (Seymour J.) wrote: > In , > on 11/05/2010 > >at 09:46 AM, "Roach, Dennis (N-GHG)" said: > > >Try the TSO EDIT command from ready some time. > > I have. > > >Make you like vi. > > No. Yes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IDCAMS ALTER and GDGs - From A(0) to B(+1) - Relative Generations
Note: This ISN'T tape we're talking about. (I'm sorry I mentioned it in passing.) Thanks for all the replies! Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Processing Compressed SMF Records with MXG
I changed the subject from the How Log For SMF to Switch to answer the question posed in that thread with regard to MXG and it's handling of compressed SMF records from CICS and (new in V10) DB2: For sites executing on z/OS, MXG 28.07 provides the ASM code in member EXITCICS to create a SAS "Infile" Exit that decompresses the SMF 110-1 CICS records and the SMF 100,101, and 102 DB2 records, transparently, once the load module is created and stored in a STEPLIB, and MXG is informed the exit exists with //SYSIN DD * %LET SMFEXIT=CICS; to enable MXG to use that decompression infile exit. In addition, if the infile exit is not installed on z/OS, or if MXG is executed on ASCII SAS (which does not provide "Infile Exits"), the compressed records are transparently processed using an internal SAS code algorithm, which, unfortunately is VERY CPU EXPENSIVE on z/OS. (So expensive MXG prints ERROR messages when the internal algorithm is used on z/OS where the EXITCICS algorithm should be used.) On z/OS, for CICS, the IBM utility DFH$MOLS will decompress the SMF 110 subtype 1 records, but there is (at present) no IBM utility that decompresses the DB2 V10 SMF records. The below note from the NEXT MXG NEWSLETTER www.mxg.com/newsltrs compares processing of compressed CICS SMF records. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com admin questions: ad...@mxg.com technical questions: supp...@mxg.com tel: 214 351 1966 fax: 214 350 3694 1. Processing Compressed CICS data on z/OS and on Windows. An SMF file of 125,712 ID=110 records that created 267,899 CICSTRAN transactions was 212 MB when IBM Compression was enabled, and was 970 MB when uncompressed by the IBM utility DFH$MOLS. The example JCL for CICS decompression is in new DFH$MOLS member in MXG 28.06. On z/OS, three alternatives exist to process compressed CICS data: a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED. b. Use EXITCICS (SAS Infile Exit) to read COMPRESSED WITH EXIT. c. Use MXG's internal SAS code to read COMPRESSED WITH INTERNAL. Average 7 runs:ElapsedTCBSRB EXCP Connect Size (min)(min) (min) (sec) a. DFH$MOLS.8 .07.00 53158 11.2 212/970 UNCOMPRESSED 2.0 .62.01 47934 11.3 970 MB total 2.8 .69.01 101092 22.5 b. COMP WITH EXIT 2.3 .70.00 145495.7 212 MB c. INTERNAL SAS 22.4 9.88.00 145545.7 212 MB As previously reported, the INTERNAL SAS algorithm on z/OS is VERY CPU intensive (and it takes a long time, too!). DFH$MOLS and read UNCOMPRESSED is only slightly slower than reading COMPRESSED+EXIT, but the uncompressed file needs nearly 5 times the disk space for the (temporary) uncompressed file, and I/O activity with DFH$MOLS (read compressed, write uncompressed, then read uncompressed) took six times the EXCPs and four times the IOTM (Connect Time), so the reading of the compressed file with the EXITCICS exit is best. On Windows/ascii platforms, SAS Infile Exits do not exist (and, if they existed, the ASM code in EXITCICS couldn't execute on ASCII), so if the SMF data file is downloaded and then processed, there are only two ways to process compressed CICS data: a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED. c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT. Elapsed User SYSSize a. DFH$MOLS.4 .07.00 212/970 ftp download 2.0 .04.00970 MB UNCOMPRESSED.4 .23.05970 MB total2.8 .34.05 c. ftp download 2.0 .04.00212 MB INTERNAL SAS 3.8 2.71.05212 MB total5.8 2.75.05 The internal algorithm on Windows is only ten times as CPU intensive reading the compressed file, compared to reading uncompressed, but a lot more disk space is needed for the uncompressed file. Unfortunately, at this test site, we were not able to use the SAS ftp access method on ASCII to read the uncompressed and compressed files directly from z/OS, without download, for that comparison, but prior tests using the access method to directly read z/OS files have always been cheaper and faster than reading the downloaded files, so I would expect that if you can tolerate the temporary disk space on z/OS for the uncompressed file, using DFH$MOLS first would be best. -- For IBM-MAIN subscribe
PDOS/390
I've just uploaded a new version of PDOS/390 here: http://sourceforge.net/projects/pdos/files/pdos/pdos-stage67.zip/download This beta is far better than previous betas, and is actually good enough to allow GCC to self-compile under it. Obviously there's still a lot lacking, but that is at least one real-world task that PDOS/390 can do. And it does it with the natural filenames that GCC uses by default too. A lot of people downloaded the previous beta, but no reports of anyone successfully using it on real iron. It should be in with a shot at working on real iron so long as a telnet connection is used (ie it doesn't support 3270 currently). BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
On Sat, 6 Nov 2010 11:06:09 -0400, J R wrote: >I'm not sure I buy this highly speculative explanation. > >There's a big difference between not allowing multiple blocks per member and >not considering second blocks to be necessary. Furthermore, to "solve" the >problem by introducing multiple members per userid, rather than multiple >blocks per member, defies credibility. > I'm highly speculating about the possibility of update-in-place. If UADS management employs update-in-place, the only way to extend a member is to introduce an overflow member. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rexx question - Dynamic generation of variables?
On Sat, 6 Nov 2010 08:33:02 -0500, Joel C. Ewing wrote: > >Since the stem index is an arbitrary variable value, whenever I have >needed a table lookup dependent on multiple variable values I have >usually been able to use a construct like > >table. = 'some default value' >... >index = dsname "#" volser "#" lpar >table.index = 'some value' > >and then use a similar setting of "index" before using "table.index" to >lookup a value in the table. > >This technique in effect maps any number of dimensions to a single >dimension. > Of course: table.dsname.volser.lpar = 'some value' is simpler. I can imagine only two reasons for manufacturing the index. o The '.' character may appear in dsnames, allowing ambiguity. But it's still safe if neither of the other two tail components can contain '.'. And since '#', like '.' can appear in dsnames, you gain nothing by using it as a delimiter. Best use a delimiter that's prohibited in all tail components. Even here there's a hazard. JCL allows (or allowed a couple decades ago) any code point in a volser surrounded by apostrophes. In a POC back then, we discovered that a volser starting with x'FF' was taken as a special form where the remaining five bytes contained a memory address. Strange program checks in label processing. o Generating the tail separately allows NOVALUE signals, detecting possible undefined variables. Explicit use of an undefined symbol in a compound tail does not signal NOVALUE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IDCAMS ALTER and GDGs - From A(0) to B(+1) - Relative Generations
With the nature of the last eight characters of a GDS name, the likelihood of
it not changing between FILE1 and FILE2 is very low. If the GDS is on tape,
renaming is not an option.
> Date: Sat, 6 Nov 2010 09:53:53 -0500
> From: sba...@sbbworks.com
> Subject: Re: IDCAMS ALTER and GDGs - From A(0) to B(+1) - Relative Generations
> To: IBM-MAIN@bama.ua.edu
>
> If a tape dataset name is 17 characters or longer (and the last 17
> characters do not change), I believe that it can be renamed, using a DEFINE
> NVSAM command (with DEVTYPE, VOLUMES and optionally FSEQN), along with the
> requisite DELETE '' NOSCRATCH command. At least with CA-1, there are
> TMC update utilities TMSUPDTE and TMSUDSNB ("restricted use" though), as
> well, to consider using with this activity, where any DSN length is a
> candidate for change.
>
> Scott Barry
> SBBWorks, Inc.
>
>
> On Fri, 5 Nov 2010 14:37:21 -0700, Ulrich Krueger wrote:
>
> >Martin,
> >Unless something changed since the last time I looked at this ...
> >You cannot rename a dataset on tape.
> >1) Your tape management system probably wouldn't like it.
> >2) The physical tape label info can not be changed after the tape has been
> >created.
> >
> >AFAIK, your only way to "rename a tape dataset" is to copy it to a new tape.
> >
> >
> >Regards,
> >Ulrich Krueger
> >
> >-Original Message-
> >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
> >Of Martin Packer
> >Sent: Friday, November 05, 2010 12:54 PM
> >To: IBM-MAIN@bama.ua.edu
> >Subject: IDCAMS ALTER and GDGs - From A(0) to B(+1) - Relative Generations
> >
> >I'm looking at a customer batch job and they are rolling over 12 monthly
> >files by 1 - the oldest going off to another data set on tape. They are
> >doing this with ICEGENER copy steps. Each monthly file is a different GDG.
> >Rather than do the actual copying I'd like them to explore using some form
> >of rename.
> >
> >In this case it boils down to renaming FILE1(0) to FILE2(+1). IDCAMS ALTER
> >will do it with hardcoded generations and versions. I checked this and
> >that the structure of the target GDG was intact - by coding some JCL on my
> >own system.
> >
> >However, I'd prefer not to have to recommend absolute generations and
> >versions. Does anyone know how to do this with (0) and (+1)?
> >
> >Yes, I'm aware there may be some operational difficulties with this
> >approach - we didn't keep n generations this way. I'm not convinced the
> >customer actually wants to. I want to present them with options.
> >
> >Thanks, Martin
> >
> >Martin Packer,
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
I'm not sure I buy this highly speculative explanation. There's a big difference between not allowing multiple blocks per member and not considering second blocks to be necessary. Furthermore, to "solve" the problem by introducing multiple members per userid, rather than multiple blocks per member, defies credibility. At best, this is a non sequitur. The OP's question was, "Why are TSO IDs limited to 7 characters?" The explanation given relies on the fact that the userid was already defined as less than eight characters. I used TSO under MVT in the early '70s on 2741s (and SPF, but not on 2741s) and the notion that the seven character userid plus one byte length was specifically to make it fit in a doubleword seems a stretch. Sitting at a 2741, the response time was such that the thought that the code had been optimized in such detail never entered one's head. I agree that TSO still works extremely well today, so I'm not knocking its design. However, if IBM were to increase the maximum userid length, a lot of 40 year old software would stop working. > Date: Sat, 6 Nov 2010 08:01:46 -0600 > From: rfocht...@ync.net > Subject: Re: Why are TSO IDs limited to 7 characters > To: IBM-MAIN@bama.ua.edu > > The original UADS dataset blksize was dictated by the DASD devices of > the time, which sometimes included track sizes of 2000 bytes (2321, for > example). The design of UADS and the code that used it would not allow > multiple blocks per member, because no second block was ever considered > necessary. Later, when the information content increased, the solution > implemented was multiple members, based on the seven-character (or less) > user id, suffixed with a numeric digit. The sequence always started with > zero and went up from there. > > Also, some of the TSO control blocks contained the USERID length in the > first character, followed by up to a seven-character userid. Alignment > sensitivies required that this information all fit into a double-word, > so that succeeding fields in the block could be kept aligned and still > minimize the space required. Recall that the S/360, where TSO was > originally designed, was very sensitive to alignment issues and there > was no virtual storage to expand blocks, etc. S0C5 abends were quite > common, whereas they are almost unheard-of today. > > Considering how old TSO really is, I'm surprised that it still works as > well as it does today, while still maintaining backward compatability. :-) > > Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IDCAMS ALTER and GDGs - From A(0) to B(+1) - Relative Generations
If a tape dataset name is 17 characters or longer (and the last 17
characters do not change), I believe that it can be renamed, using a DEFINE
NVSAM command (with DEVTYPE, VOLUMES and optionally FSEQN), along with the
requisite DELETE '' NOSCRATCH command. At least with CA-1, there are
TMC update utilities TMSUPDTE and TMSUDSNB ("restricted use" though), as
well, to consider using with this activity, where any DSN length is a
candidate for change.
Scott Barry
SBBWorks, Inc.
On Fri, 5 Nov 2010 14:37:21 -0700, Ulrich Krueger wrote:
>Martin,
>Unless something changed since the last time I looked at this ...
>You cannot rename a dataset on tape.
>1) Your tape management system probably wouldn't like it.
>2) The physical tape label info can not be changed after the tape has been
>created.
>
>AFAIK, your only way to "rename a tape dataset" is to copy it to a new tape.
>
>
>Regards,
>Ulrich Krueger
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
>Of Martin Packer
>Sent: Friday, November 05, 2010 12:54 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: IDCAMS ALTER and GDGs - From A(0) to B(+1) - Relative Generations
>
>I'm looking at a customer batch job and they are rolling over 12 monthly
>files by 1 - the oldest going off to another data set on tape. They are
>doing this with ICEGENER copy steps. Each monthly file is a different GDG.
>Rather than do the actual copying I'd like them to explore using some form
>of rename.
>
>In this case it boils down to renaming FILE1(0) to FILE2(+1). IDCAMS ALTER
>will do it with hardcoded generations and versions. I checked this and
>that the structure of the target GDG was intact - by coding some JCL on my
>own system.
>
>However, I'd prefer not to have to recommend absolute generations and
>versions. Does anyone know how to do this with (0) and (+1)?
>
>Yes, I'm aware there may be some operational difficulties with this
>approach - we didn't keep n generations this way. I'm not convinced the
>customer actually wants to. I want to present them with options.
>
>Thanks, Martin
>
>Martin Packer,
>Mainframe Performance Consultant, zChampion
>Worldwide Banking Center of Excellence, IBM
>
>+44-7802-245-584
begin_of_the_skype_highlighting +44-7802-245-584 end_of_the_skype_highlighting
>
>email: martin_pac...@uk.ibm.com
>
>Twitter / Facebook IDs: MartinPacker
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tivoli Storage Manager for z/OS (Functionally Stablized & Impending Demise)
If IBM cannot or will not support z/OS in this roll there are good third party software vendors who do like Innovation. This will preserve your investment in z/OS and maintain the z/OS qualities of service and economies of scale you have today. http://www.fdr.com/products/upstream/index.cfm http://www.fdr.com/products/upstreamunix/ http://www.fdr.com/index.cfm Best Regards, Sam Knutson -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Saturday, November 06, 2010 8:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Tivoli Storage Manager for z/OS (Functionally Stablized & Impending Demise) On 11/5/2010 5:38 AM, Jim Marshall wrote: > Question - 1: > > "SO" I would like to know who are the other four people who had a similar idea > about using TSM for z/OS, to be the data backup place in order to leverage all > the good things z/OS has to offer. I guess we're one of the other four. TSM for z/OS works great for us. It's hooked into our mainframe-based "cron" facilities, uses large DASD EAVs, uses the same tapes and drives that HSM uses--which get moved by RMM to the same off-site locations, etc. I really don't want to try to come up with an alternate PC and zFS file backup strategy... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tivoli Storage Manager for z/OS (Functionally Stablized & Impending Demise)
edja...@phoenixsoftware.com (Edward Jaffe) writes: > I guess we're one of the other four. TSM for z/OS works great for > us. It's hooked into our mainframe-based "cron" facilities, uses large > DASD EAVs, uses the same tapes and drives that HSM uses--which get > moved by RMM to the same off-site locations, etc. I really don't want > to try to come up with an alternate PC and zFS file backup strategy... ... random trivia ... started as cmsback that I implemented in the late 70s for internal use. cmsback went thru several internal releases before morphing into "workstation datasave" for product release. It then morphed into ADSM ... adstar storage manager ... in the period of the early 90s when the disk division was renamed (adstar) as part of anticipation of being spun off as independent business. That decision was reversed after new management was brought in (after the company had gone into the red). However, later the disk business unit was sold off ... however ADSM morphed into TSM tsm wiki page http://en.wikipedia.org/wiki/IBM_Tivoli_Storage_Manager old cmsback related email http://www.garlic.com/~lynn/lhwemail.html#cmsback one of the early cmsback adopters was HONE ... one of my favorite and long-term internal customers for my highly modified operating systems. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
--- I used 2741 with TSO on SVS. Line mode only. ISPF did not exist. Its predecessor (SPF/PDF) required 3270. All working from TSO READY. Try the TSO EDIT command from ready some time. Make you like vi. Also made RAX look ultra-modern. :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
I am quite convinced TSO was from a later period, after MVT and with 3270 screens. In the distant past, I used TSO on 2741 terminals, as well as 2260 "tubes" Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
-- This is a curiosity question sparked by another thread. The limitation of 7 characters for TSO IDs has caused us extra work in the past (we use IDs of 3-8 characters across the institution, but the mainframe can't use the institutional IDs in part because of this limitation). True, very true. It's a cultural/environmental fact that IBM should be sensitive to; it falls in the category of "Plays Well with Others". IBM should even consider leapfrogging the competition and allowing more than 8, such as 25 or 50, or even flexible upper limit. I believe RACF will allow creating an OMVS segment with an 8-character ID, compatible with prevalent institutional IDs. What would happen if a user with such an ID submitted a batch job, or issued the Rexx "address TSO" instruction? Originally, TSO/E user IDs were kept in the User Attribute Data Set (UADS), a PDS. User IDs with few attributes fit in a single member. User IDs with many attributes overflow into multiple members. The member naming convention is USERIDn, where n is a digit from 0 (the first member) to 9. You can control when IDs overflow by changing the block size; smaller block sizes split sooner, and larger ones split later. TSO/E looks at all the USERIDn members when you log on to retrieve all your user attributes. I'm trying to imagine what could have limited the size of each UADS member? Was each member required to fit in one block? Surely issuing a single FIND and multiple READS should have been cheaper than concocting multiple member names and issuing a FIND for each, then READs. Was the processing sensitive to block boundaries, with the only way to control the placement of block boundaries being creation of artificial member boundaries? The original UADS dataset blksize was dictated by the DASD devices of the time, which sometimes included track sizes of 2000 bytes (2321, for example). The design of UADS and the code that used it would not allow multiple blocks per member, because no second block was ever considered necessary. Later, when the information content increased, the solution implemented was multiple members, based on the seven-character (or less) user id, suffixed with a numeric digit. The sequence always started with zero and went up from there. Also, some of the TSO control blocks contained the USERID length in the first character, followed by up to a seven-character userid. Alignment sensitivies required that this information all fit into a double-word, so that succeeding fields in the block could be kept aligned and still minimize the space required. Recall that the S/360, where TSO was originally designed, was very sensitive to alignment issues and there was no virtual storage to expand blocks, etc. S0C5 abends were quite common, whereas they are almost unheard-of today. Considering how old TSO really is, I'm surprised that it still works as well as it does today, while still maintaining backward compatability. :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rexx question - Dynamic generation of variables?
On 11/05/2010 07:24 PM, Gibney, Dave wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Phil Smith Sent: Friday, November 05, 2010 5:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Rexx question - Dynamic generation of variables? "Stems are not arrays." Not now, not ever. But in some ways they're more powerful, as they let you do associative memory. That's why I decided on Rexx, I want what is in effect a 3 dimensional associative memory space. Dsname X volser X Lpar. -- ...phsiii Phil Smith III p...@voltage.com Voltage Security, Inc. www.voltage.com ... Since the stem index is an arbitrary variable value, whenever I have needed a table lookup dependent on multiple variable values I have usually been able to use a construct like table. = 'some default value' ... index = dsname "#" volser "#" lpar table.index = 'some value' and then use a similar setting of "index" before using "table.index" to lookup a value in the table. This technique in effect maps any number of dimensions to a single dimension. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tivoli Storage Manager for z/OS (Functionally Stablized & Impending Demise)
On 11/5/2010 5:38 AM, Jim Marshall wrote: Question - 1: "SO" I would like to know who are the other four people who had a similar idea about using TSM for z/OS, to be the data backup place in order to leverage all the good things z/OS has to offer. I guess we're one of the other four. TSM for z/OS works great for us. It's hooked into our mainframe-based "cron" facilities, uses large DASD EAVs, uses the same tapes and drives that HSM uses--which get moved by RMM to the same off-site locations, etc. I really don't want to try to come up with an alternate PC and zFS file backup strategy... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are TSO IDs limited to 7 characters
And then there were those of us "fortunate" enough to have also experienced the Fujitsu/FACOM equivalents. One significant contributor to this list has even admitted appreciating the opportunity. No accounting for taste ... Shane ... On Sat, 6 Nov 2010 02:13:23 -0400 "Robert A. Rosenberg" wrote: > I beg to differ. Originally there was SPF with an optional product > called PDF which ran under it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
