Dfsmsdfp

[Scott Ford]

All,

I am calling a program passing an alternate ddname list for sysin/sysprint. Are 
there dfsms exits that will prevent me from doing this ?


Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[Shane Ginnane]

On Fri, 8 Feb 2013 11:52:14 -0600, Tom Wasik wrote:

>More detail will be presented at the next SHARE so come to Boston and learn a 
>lot more.

Thanks Tom, nice info. Seems like lots of functionality coming we've all been 
hanging out for - for years ...  :-)

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: blksize for ML2 migrated dataset via HSM

[Neil Duffee]

Caveat:  I get the daily digest so you folx've probably already hashed this to 
death...

Not sure about signed/unsigned but CA-1(R) r12.6 will not store a value 
>032760.  FDR/ABR dumps backup records in approx. track length ie. 57k-ish for 
our 3390-3s, but they are recorded with the 032760 value in CA-1.  I discovered 
this while trying to generate an Earl report showing the amount of data stored 
on our tapes.  ("How many 3592 tapes would we have to buy?")  Had to manually 
fudge the results for FDR/ABR tapes otherwise I was under-reporting them by 
1-(32/57) percent.

>  signature = 6 lines follows  <
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585  fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
"How *do* you plan for something like that?"  Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent"  John Norgauer 2004


-Original Message-
From: retired mainframer [mailto:retired-mainfra...@q.com] 
Sent: February 7, 2013 21:04
Subject: Re: blksize for ML2 migrated dataset via HSM

If memory serves, the CA1 TMC uses 16 bits to store the blksize.  Even when 
treated as unsigned, it won't show more than 65535.
[snip]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Check out Associated Press-Big snow in Northeast.

[R.S.]

W dniu 2013-02-08 19:30, Ed Finnell pisze:

_Associated  Press_
(http://hosted2.ap.org/APDEFAULT/3d281c11a96b4ad082fe88aa0db04305/Article_2013-02-08-Northeast%20Snow/id-3e9597311a9b4923bcf53839ab7
a152a)

Only a travel warning for those stuck in Anaheim-say hi to  Mickey!


Well, I saw weather report - they warned about big snow in South, 
especially Zakopane, Kraków, Rzeszów. Not sure about Wytrzyszczka, 
Chrzczonowice, Szczebrzeszyn and Szczyrk.




--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS v2.1 preview

[Scott Ford]

Martin,

I am a developer, but that doesn't mean people listen...

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 8, 2013, at 4:03 AM, Martin Packer  wrote:

> Do you know if this is the "standard" RegExp functions callable from C 
> that are driving this? I've advised various developers that if z/OS 
> product functions standardise on using these we:
> 
> 1) All know what to expect - and the skills are interchangeable from tool 
> to tool.
> 
> 2) Can beat up on the one development team for any enhancements that might 
> be needed.
> 
> Disclaimer: I'm not a product developer and nobody has to listen to me. 
> :-)
> 
> Cheers, Martin
> 
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Banking Center of Excellence, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> Blog: 
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> 
> 
> From:   Mark Zelden 
> To: IBM-MAIN@listserv.ua.edu, 
> Date:   02/07/2013 10:58 PM
> Subject:Re: z/OS v2.1 preview
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> I just downloaded a current  version of SPFlist  (was running 4.3, current 
> is 6.1)
> and found out is supports regular expressions now.   http://spflite.co.nr/
> 
> I don't know what ISPF's implementation will be like, but for SPFLite
> you use FIND R'regular expression'. 
> 
> So I can play with this now.  :-) 
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS 
> mailto:m...@mzelden.com 
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
> Systems Programming expert at http://expertanswercenter.techtarget.com/
> 
> 
> 
> On Tue, 5 Feb 2013 20:23:48 +, Martin Packer 
>  wrote:
> 
>> I think you're going to like them, Mark. Not that I've found a system to
>> play with this on yet.
>> 
>> Cheers, Martin
>> 
>> Martin Packer,
>> zChampion, Principal Systems Investigator,
>> Worldwide Banking Center of Excellence, IBM
>> 
>> +44-7802-245-584
>> 
>> email: martin_pac...@uk.ibm.com
>> 
>> Twitter / Facebook IDs: MartinPacker
>> Blog:
>> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>> 
>> 
>> 
>> From:   Mark Zelden 
>> To: IBM-MAIN@listserv.ua.edu,
>> Date:   02/05/2013 07:48 PM
>> Subject:Re: z/OS v2.1 preview
>> Sent by:IBM Mainframe Discussion List 
>> 
>> 
>> 
>> I know of at least a few people on this list that will love this one:
>> 
>> "The ISPF editor is planned to allow regular expressions to be
> specified
>> as
>> arguments to the FIND and CHANGE commands. "
>> 
>> I've even used Doug Nadel's FINDRX macro a few times, but admit I still
>> don't really "get" regular expressions (I'm sure if I used *nix more
>> I would).
>> 
>> 
>> --
>> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
>> mailto:m...@mzelden.com
>> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
>> Systems Programming expert at http://expertanswercenter.techtarget.com/
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 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...@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
> 
> 
> 
> 
> 
> 
> 
> 
> 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...@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: SFTP vs. FTPS (was: z/OS v2.1 preview)

[Scott Ford]

Kirk is correct, Z/os is posix ...uses posix C 

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 8, 2013, at 8:59 AM, Kirk Wolf  wrote:

> On Thu, Feb 7, 2013 at 7:15 PM, Paul Gilmartin  wrote:
> 
>> On Thu, 7 Feb 2013 14:20:02 -0600, Kirk Wolf wrote:
>> 
>>> Walt,
>>> 
>>> You are correct - FTP is more prevalent in z/OS shops.
>>> 
>>> SFTP is much more prevalent in distributed systems since OpenSSH is
>>> installed as a default package on all modern Unix/Linux distros.   Also,
>>> SSH/SFTP uses a single port/connection which has significant advantages
>>> when it comes to navigating modern networks.
>> Did you intend to disqualify OMVS as a "modern Unix/Linux distro"?
> (Sorry if my sarcasm detector isn't working for your post, but) yeah -
> z/OS is not a Unix/Linux distro :-)   z/OS Unix isn't either - its a POSIX
> layer for z/OS.
> 
> Also, a Unix system isn't complete without the full GNU suite, IMO.
> 
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.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

Check out Associated Press-Big snow in Northeast.

[Ed Finnell]

_Associated  Press_ 
(http://hosted2.ap.org/APDEFAULT/3d281c11a96b4ad082fe88aa0db04305/Article_2013-02-08-Northeast%20Snow/id-3e9597311a9b4923bcf53839ab7
a152a)  
 
Only a travel warning for those stuck in Anaheim-say hi to  Mickey!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SFTP vs. FTPS (was: z/OS v2.1 preview)

[Shmuel Metz (Seymour J.)]

In
,
on 02/08/2013
   at 07:59 AM, Kirk Wolf  said:

>(Sorry if my sarcasm detector isn't working for your post, but) 
>yeah -  z/OS is not a Unix/Linux distro :-)   z/OS Unix isn't 
>either - its a POSIX layer for z/OS.

It's certified as Unix, and X/Open is at least as relevant as POSIX.

>Also, a Unix system isn't complete without the full GNU suite, IMO.

GNU is Not Unix (-;

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[Tom Wasik]

>It there aren't enough blanks to compress out, will the line be extended,
possibly reallocating a buffer if necessary?  (I'm assuming RECFM=VB
for the SYSIN.

If there are not enough blanks, then the length of the line is extended.  If 
the application or utility passes in a large enough buffer, the full record is 
passed (with the correct length).  If not large enough, then an I/O error 
(buffer too small) is returned.  Application that read SPOOL using ACBs/RPLs 
(not really documented) are passed the actual length and they can come back in 
with a larger buffer and get the full record.  DCB interface is probably going 
to just fail.

>So the value of a very dynamic system symbol such as TIME could vary
from line to line within the same SYSIN?

Yes, that is true.  If you need it to be static, then set a JCL variable to the 
value and use that as variable in the instream data set.  You can now use 
system symbols in batch JCL.

More detail will be presented at the next SHARE so come to Boston and learn a 
lot more.

Tom Wasik
JES2 Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[Paul Gilmartin]

On Fri, 8 Feb 2013 10:15:25 -0600, Tom Wasik wrote:
>
>The way the substitution works is it looks to compress blanks to the right of 
>the symbol.  It will compress strings down to 1 characters trying to keep 
>characters in the same column that they are in.
> 
Programmers most familiar with ISPF editor will welcome this behavior;
those more familiar with POSIX here-documents may be less comfortable
with it.  But it's useful.

It there aren't enough blanks to compress out, will the line be extended,
possibly reallocating a buffer if necessary?  (I'm assuming RECFM=VB
for the SYSIN.

>The substitution happens "just in time" as the application is running to pick 
>up the latest JES symbols.  JES symbols are dynamic as opposed to JCL symbols 
>that are static.
> 
So the value of a very dynamic system symbol such as TIME could vary
from line to line within the same SYSIN?

>I did not mention PARMDD because it did not hit JES2 at all so there was 
>nothing to really talk about.
> 
A short PDF on syntax with continuation conventions would yet
be welcome.  But I suppose the Reference will happen soon enough.

So for BPXWDYN the programmer will have his choice of PARMDD or
STDPARM.  I wonder if it makes any difference?

Thanks again,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JES2 Hist from Jack Schudel(ret.)

[John Gilmore]

Under IBSYS for the IBM 7094 printed and punched output was often said
to be 'spooled' to tape for subsequent printing and punching under the
control of an IBM 1401.

'Backronym' is, I suppose, inevitable as a nonce term; but I should be
sorry to see such a barbarism come into wide use.  The standard
distinction is that between analytic and synthetic acronyms.

This distinction is sometimes hard to make and sometimes not.  I
learned of The US Department of Energy's

Innovative and Novel Computational Impact on Theory and Experiment (INCITE)

initiative from an IBM press release last year; and it is clear beyond
argument that INCITE is a synthetic acronym, but the case under
discussion is less clear: it is probably a mixed one.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JES2 Hist from Jack Schudel(ret.)

[Shmuel Metz (Seymour J.)]

In <51145fd3.5010...@valley.net>, on 02/07/2013
   at 09:15 PM, Gerhard Postpischil  said:

>I had one question - he describes the ASP precurser as a 
>7090/7094 complex. I was not aware of any such. The one I ran on 
>at NASA's Goddard Space Flight Center (Greenbelt, MD) had a 7044 
>controlling a 7094II. So  was this a later, improved version?

I highly doubt it. The unit record equipment on the 7090 was based on
EAM equipment, and excrutiatingly slow; the 7040 and 7044 had
essentially the same unit record equipment as the 1401. The only DCS
combinations I'm aware of are 7040/7090 and 7044/7094.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: basic SMS question

[Pew, Curtis G]

On Feb 8, 2013, at 10:41 AM, "Gibney, Dave"  wrote:

> Which of the many DATACLAS attributes do you wish to change. Most are 
> physical aspects of the actual existing dataset. Just changing the 
> description will have no effect. These attributes are fixed when the dataset 
> is created. Re-creation and copying the data is the only effective way to 
> change most if not all DATACLAS attributes.
> 
> I will ask again, what is the real underlying problem you want to solve?

Exactly. A DATACLAS is a set of defaults applied when the file is created (and 
any particular attribute set by the DATACLAS may be overridden at creation 
time.) Once the data set exists, what does it matter what its DATACLAS is?

-- 
Curtis Pew (c@its.utexas.edu)
ITS Systems Core
The University of Texas at Austin

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: basic SMS question

[Gibney, Dave]

Which of the many DATACLAS attributes do you wish to change. Most are physical 
aspects of the actual existing dataset. Just changing the description will have 
no effect. These attributes are fixed when the dataset is created. Re-creation 
and copying the data is the only effective way to change most if not all 
DATACLAS attributes.

I will ask again, what is the real underlying problem you want to solve?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jim McAlpine
> Sent: Friday, February 08, 2013 1:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: basic SMS question
> 
> I've found another error in the data class selection routines which
> means that datasets have been converted but not assigned the correct
> data class.
> What is the quickest way to reassign a data class (or storage class
> come to that).  Do I have to CONVERTV to NONSMS and then CONVERTV to
> SMS again or is there some quicker method.
> 
> Jim McAlpine
> 
> On Thu, Feb 7, 2013 at 4:11 PM, Jim McAlpine 
> wrote:
> 
> > Thanks for the explanation.  Much appreciated.
> >
> > Jim McAlpine
> >
> >  On Thu, Feb 7, 2013 at 3:51 PM, Darth Keller
> wrote:
> >
> >> A couple of things -
> >>
> >> &DSN(2) = 'DSNDBD'   -  'DSNDBD' in the 2nd level generally
> identifies
> >> the data component of a DB2 LDS.  Data components do not get
> assigned
> >> their own SMS Constructs.  Constructs are assigned at the cluster
> >> level. I see this as useless code unless your shop is actually using
> >> cluster names with DSNDBD as the 2nd level.
> >>
> >> 2ndly - the answer to your question is going to depend on what's in
> >> the filterlist &DB2E.
> >>
> >> If it contains an entry like DB2E.**   , then all those datasets
> would
> >> be assigned SCDB2 in the &DSN(1) segment and then re-assigned SCSMS
> in the
> >> SELECT/WHEN you've shown us.   This is a result of not having a EXIT
> in
> >> the first set of statements - the allocation falls through into the
> >> next code segment and gets re-evaluated.  And it will continue to be
> >> re-evaluated after your
> >> SET &STORCLAS = 'SCSMS'as that statement also doesn't appear to
> have a
> >> paired EXIT.
> >>
> >> Without the WRITE stmts Lisa mentioned, it's pretty hard to tell
> from
> >> what you've shown us.  Your allocation could actually have several
> >> storage classes assigned and re-assigned, with some other segment
> >> having the final assignment of 'SCSMS' before it finally falls out
> of SMS.
> >>
> >> My general rule of thumb is that the only time I don't pair a SET
> >> with an EXIT is when I want to set a default StorCLas.  I always
> pair
> >> a SET with a WRITE and generally its a SET, WRITE, & EXIT.
> >>
> >> I'd recommend investigating NAVIQUEST to use in testing your code &
> >> any changes you're thinking of making.
> >> ddk
> >>
> >>
> >> 
> >>
> >>
> >> I've inherited an SMS setup and I know little about SMS but this I
> >> know isn't working.  In the storage class ACS routines is this
> >> snippet -
> >>
> >>  IF &DSN(1) = 'DB2E' THEN
> >>   DO
> >> IF &DSN(2) = 'DSNDBC' THEN
> >>   DO
> >> SET &STORCLAS='SCDB2'
> >>   END
> >> IF &DSN(2) = 'DSNDBD' THEN
> >>   DO
> >> SET &STORCLAS='SCDB2'
> >>   END
> >>   END
> >> followed by this -
> >>
> >> SELECT
> >> WHEN (&DSN = &DB2E)
> >>   SET &STORCLAS = 'SCSMS'
> >> Question.  Any dataset of the form DB2E.DSNDBC.** is getting the
> >> storage class SCSMS and not SCDB2 which is what is required.  I want
> >> all
> >> DB2E.DSNDBC.** datasets to get SCDB2 and any other DB2E.** dataset
> to
> >> get SCSMS.  What is wrong with the above syntax please.
> >>
> >> Jim McAlpine
> >>
> >>
> >>
> >>
> >>
> >> This e-mail message and all attachments transmitted with it may
> >> contain legally privileged and/or confidential information intended
> >> solely for the use of the addressee(s). If the reader of this
> message
> >> is not the intended recipient, you are hereby notified that any
> >> reading, dissemination, distribution, copying, forwarding or other
> >> use of this message or its attachments is strictly prohibited. If
> you
> >> have received this message in error, please notify the sender
> >> immediately and delete this message and all copies and backups
> >> thereof. Thank you.
> >>
> >> 
> -
> >> - 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

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[David Andrews]

On Fri, 2013-02-08 at 11:03 -0500, zMan wrote:
> Sorry to seem dense -- is that a "no"?

I didn't answer your question (sorry), but you brought to mind an
interesting caveat.  Read-time has 1001 uses, and probably a couple of
gotchas.  Excuse my digression.

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS v2.1 preview

[John Gilmore]

John Eels wrote,

| How else would (or should) we let people know?

and his point is well taken.  Piggybacking this information on the
z/OS 2.1 (sic) preview was entirely appropriate.  The text used was
less so.  It should have been clearer about scope, retrofitting, and
the like.

There would of course have been questions---How not? Finding
ambiguities in IBM announcements is, oddly, some people's favorite
indoor sport---no matter how impeccable this language had been, but
their number would have been smaller if it had been better.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[Tom Wasik]

The SYMBOLS= keyword is on the DD DATA or DD * JCL.  It controls what symbols 
are substituted in the instream data sets ... so yes, in places like:
REPRO INFILE(GIMZPOOL) +
 OUTDATASET(&HLQ..GLOBAL.CSI)

The way the substitution works is it looks to compress blanks to the right of 
the symbol.  It will compress strings down to 1 characters trying to keep 
characters in the same column that they are in.

The substitution happens "just in time" as the application is running to pick 
up the latest JES symbols.  JES symbols are dynamic as opposed to JCL symbols 
that are static.

I did not mention PARMDD because it did not hit JES2 at all so there was 
nothing to really talk about.

Tom
JES2 Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[zMan]

On Fri, Feb 8, 2013 at 10:01 AM, David Andrews  wrote:

> On Fri, 2013-02-08 at 09:29 -0500, zMan wrote:
> > Does the enhanced symbol support mean that you can use symbols in places
> > like this:
> > REPRO INFILE(GIMZPOOL) +
> >  OUTDATASET(&HLQ..GLOBAL.CSI)
>

Sorry to seem dense -- is that a "no"?
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS v2.1 preview

[John Eells]

Edward Jaffe wrote:

On 2/6/2013 6:16 AM, Paul Gilmartin wrote:

o IBM plans to remove support for unsecured FTP connections used for z/OS
   software and service delivery October 1, 2013. At that time, it is
planned
   that new System z software (products and service) downloads will
require
   the use of FTPS (FTP using Secure Sockets Layer) or of Download
Director
   with encryption.

FTPS, but not SFTP?

Is this retroactive to products older than 2.1?


As I understand things, this really has nothing to do with z/OS V2R1.
Not sure why it's in the announcement.



How else would (or should) we let people know?

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JES2 Hist from Jack Schudel(ret.)

[Joel C. Ewing]

On 02/07/2013 10:35 PM, Shmuel Metz (Seymour J.) wrote:

In <51143860.7030...@acm.org>, on 02/07/2013
at 05:27 PM, "Joel C. Ewing"  said:


The Wood history of HASP/JES2 left hanging the question about the
origin of the term "spooling".

Do you consider SPOOL System, 7070-IO-076 to be of sufficient
antiquity?
That was the earliest reference (circa 1958) I could locate as well.  It 
just seemed that the name from which the "acronym" was derived sounded 
contrived (omitting the spurious "On-Line" would have been equally 
descriptive).  But then it is not that unusual to consider multiple name 
variants for a new product; and if you choose a name which forces a more 
appealing acronym, that clouds the distinction between acronyms and 
backronyms.

Joel C Ewing


'"SPOOL" has become a common verb, but originally was itself an
acronym signifying Simultaneous Peripheral Operations On Line. This
acronym originated with the 7070 computer, which had a system of
interrupts that let one program a peripheral activity (e.g.,
card-to-tape, tape-to-print, tape-to-card) while a main program was
running.' (Dictionary of IBM Jargon, Tenth Edition)


Since early "spooling" systems staged unit records  to a spool of
magnetic tape,

I've only seen reels of tape called spools in an audio or TV context;
prior to cartridges and MSS the terms I heard were "reel" and "tape
volume".




--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting old HSM backups

[David G. Schlecht]

Thanks for the feedback. No joy finding said SAS job. 

Seems I've exhausted any solutions from this group. I'll open a ticket with IBM 
and see if there is anyone else who might have a solution.

Again, thanks for all the input.


David G. Schlecht | Information Technology Professional
State of Nevada | Department of Administration | Enterprise IT Services
T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov <-- New Address


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Gould
Sent: Thursday, February 07, 2013 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Deleting old HSM backups

I am trying to remember
Somewhere in the last 40+ years there was a SAS job that altered the MCDS (or 
was it the BCDS)?
It ran through the entire CDS in a few minutes and then you would run expirebv 
and magically all those datasets would evaporate.
I am trying to remember where the SAS job came from but cannot say for sure but 
it might have come from Berry Merrils(sp?) collection of SAS jobs, I just do 
not remember sorry. But somewhere out there is a a SAS job that marks the HSM 
cds's properly for clean up.

Ed

On Feb 7, 2013, at 12:05 PM, David G. Schlecht wrote:

> John, HBDELETE would be great if you could use a LEVEL parameter, 
> scary, but certainly better than having to run a million lines of JCL.
>
>
>
> David G. Schlecht | Information Technology Professional State of 
> Nevada | Department of Administration | Enterprise IT Services
> T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov <-- New 
> Address
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] 
> On Behalf Of John McKown
> Sent: Tuesday, February 05, 2013 3:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Deleting old HSM backups
>
> Look up the HDELETE command for migrated data sets; HBDELETE for 
> backup data sets. I'm at home now. I have some helper stuff at work. 
> I'll look for some stuff tomorrow.
> On Feb 5, 2013 4:25 PM, "David G. Schlecht"  
>  wrote:
>
>> We have been backing up millions of unnecessary datasets. I am 
>> changing HSM to not back them up but would like a reasonably easy way 
>> to delete the millions of backups that already exist.
>>
>> Is there anything short of generating millions of lines of JCL. Is 
>> there any way to get HSM to delete these backups?
>>
>> David G. Schlecht | Information Technology Professional State of 
>> Nevada | Department of Administration | Enterprise IT Services
>>
>>
>> 
>> This communication, including any attachments, may contain 
>> confidential information and is intended only for the individual or 
>> entity to which it is addressed. Any review, dissemination or copying 
>> of this communication by anyone other than the intended recipient is 
>> strictly prohibited. If you are not the intended recipient, please 
>> contact the sender by reply e-mail and delete all copies of the 
>> original message.
>>
>> -
>> -
>> 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: basic SMS question

[Vernooij, CP - SPLXM]

Ok, then I did it with CA-DISK or FDR.
Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of O'Brien, David W. (NIH/CIT) [C]
Sent: Friday, February 08, 2013 16:15
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: basic SMS question

That is correct see
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fco
m.ibm.zos.r12.idas200%2Fs2010.htm

Thank You,
Dave O'Brien
NIH Contractor

From: Don Williams [donb...@gmail.com]
Sent: Friday, February 08, 2013 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: basic SMS question

IIRC, not a DFDMDdss COPY option, either. DSS does not reformat data.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Vernooij, CP - SPLXM
> Sent: Friday, February 08, 2013 7:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: basic SMS question
>
> Correct, very irritating restriction.
> You can MOVE the dataset with DFDSS and provide a new DATACLAS then.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Brian Fraser
> Sent: Friday, February 08, 2013 13:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: basic SMS question
>
> >>ALTER data.set.name DATACLAS(newvalue)
>
> DATACLAS is not an optional parameter to IDCAMS ALTER
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only.
> If you are not the addressee, you are notified that no part of the e- 
> mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly

> prohibited, and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, and 
> delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or 
> its employees shall not be liable for the incorrect or incomplete 
> transmission of this e-mail or any attachments, nor responsible for 
> any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>
>
> --
> 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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: basic SMS question

[O'Brien, David W. (NIH/CIT) [C]]

That is correct see
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.idas200%2Fs2010.htm

Thank You,
Dave O'Brien
NIH Contractor

From: Don Williams [donb...@gmail.com]
Sent: Friday, February 08, 2013 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: basic SMS question

IIRC, not a DFDMDdss COPY option, either. DSS does not reformat data.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Vernooij, CP - SPLXM
> Sent: Friday, February 08, 2013 7:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: basic SMS question
>
> Correct, very irritating restriction.
> You can MOVE the dataset with DFDSS and provide a new DATACLAS then.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> Behalf Of Brian Fraser
> Sent: Friday, February 08, 2013 13:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: basic SMS question
>
> >>ALTER data.set.name DATACLAS(newvalue)
>
> DATACLAS is not an optional parameter to IDCAMS ALTER
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only.
> If you are not the addressee, you are notified that no part of the e-
> mail or any attachment may be disclosed, copied or distributed, and
> that any other action related to this e-mail or attachment is strictly
> prohibited, and may be unlawful. If you have received this e-mail by
> error, please notify the sender immediately by return e-mail, and
> delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> its employees shall not be liable for the incorrect or incomplete
> transmission of this e-mail or any attachments, nor responsible for any
> delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
> --
> 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: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[David Andrews]

On Fri, 2013-02-08 at 09:29 -0500, zMan wrote:
> Does the enhanced symbol support mean that you can use symbols in places
> like this:
> REPRO INFILE(GIMZPOOL) +
>  OUTDATASET(&HLQ..GLOBAL.CSI)

Tom's presentation notes that substitution is done at application *read*
time, not at conversion.

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS v2.1 preview

[zMan]

On Fri, Feb 8, 2013 at 4:03 AM, Martin Packer wrote:

> Do you know if this is the "standard" RegExp functions callable from C
> that are driving this? I've advised various developers that if z/OS
> product functions standardise on using these we:
>

XKCD must be a z/OS user: http://xkcd.com/1171/
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: basic SMS question

[Don Williams]

IIRC, not a DFDMDdss COPY option, either. DSS does not reformat data.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Vernooij, CP - SPLXM
> Sent: Friday, February 08, 2013 7:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: basic SMS question
> 
> Correct, very irritating restriction.
> You can MOVE the dataset with DFDSS and provide a new DATACLAS then.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> Behalf Of Brian Fraser
> Sent: Friday, February 08, 2013 13:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: basic SMS question
> 
> >>ALTER data.set.name DATACLAS(newvalue)
> 
> DATACLAS is not an optional parameter to IDCAMS ALTER
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only.
> If you are not the addressee, you are notified that no part of the e-
> mail or any attachment may be disclosed, copied or distributed, and
> that any other action related to this e-mail or attachment is strictly
> prohibited, and may be unlawful. If you have received this e-mail by
> error, please notify the sender immediately by return e-mail, and
> delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> its employees shall not be liable for the incorrect or incomplete
> transmission of this e-mail or any attachments, nor responsible for any
> delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
> 
> 
> --
> 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: basic SMS question

[Don Williams]

ALTER can change MGMTCLAS and STORCLAS, but not DATACLAS
My best guess is that changing the DATACLAS would imply rewritting the data,
since some DATACLAS attributes control the physical recording of data.

Don

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mike Schwab
> Sent: Friday, February 08, 2013 6:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: basic SMS question
> 
> ALTER data.set.name DATACLAS(newvalue)
> On a ISPF 3.4 line, a / picks up the data.set.name from that line.
> 
> On Fri, Feb 8, 2013 at 3:15 AM, Jim McAlpine 
> wrote:
> > I've found another error in the data class selection routines which
> means
> > that datasets have been converted but not assigned the correct data
> class.
> > What is the quickest way to reassign a data class (or storage class
> come to
> > that).  Do I have to CONVERTV to NONSMS and then CONVERTV to SMS
> again or
> > is there some quicker method.
> >
> > Jim McAlpine
> >
> > On Thu, Feb 7, 2013 at 4:11 PM, Jim McAlpine 
> wrote:
> >
> >> Thanks for the explanation.  Much appreciated.
> >>
> >> Jim McAlpine
> >>
> >>  On Thu, Feb 7, 2013 at 3:51 PM, Darth Keller
> wrote:
> >>
> >>> A couple of things -
> >>>
> >>> &DSN(2) = 'DSNDBD'   -  'DSNDBD' in the 2nd level generally
> identifies
> >>> the data component of a DB2 LDS.  Data components do not get
> assigned
> >>> their own SMS Constructs.  Constructs are assigned at the cluster
> level. I
> >>> see this as useless code unless your shop is actually using cluster
> names
> >>> with DSNDBD as the 2nd level.
> >>>
> >>> 2ndly - the answer to your question is going to depend on what's in
> the
> >>> filterlist &DB2E.
> >>>
> >>> If it contains an entry like DB2E.**   , then all those
> datasets would
> >>> be assigned SCDB2 in the &DSN(1) segment and then re-assigned SCSMS
> in the
> >>> SELECT/WHEN you've shown us.   This is a result of not having a
> EXIT in
> >>> the first set of statements - the allocation falls through into the
> next
> >>> code segment and gets re-evaluated.  And it will continue to be
> >>> re-evaluated after your
> >>> SET &STORCLAS = 'SCSMS'as that statement also doesn't appear to
> have a
> >>> paired EXIT.
> >>>
> >>> Without the WRITE stmts Lisa mentioned, it's pretty hard to tell
> from what
> >>> you've shown us.  Your allocation could actually have several
> storage
> >>> classes assigned and re-assigned, with some other segment having
> the final
> >>> assignment of 'SCSMS' before it finally falls out of SMS.
> >>>
> >>> My general rule of thumb is that the only time I don't pair a SET
> with an
> >>> EXIT is when I want to set a default StorCLas.  I always pair a SET
> with a
> >>> WRITE and generally its a SET, WRITE, & EXIT.
> >>>
> >>> I'd recommend investigating NAVIQUEST to use in testing your code &
> any
> >>> changes you're thinking of making.
> >>> ddk
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>> I've inherited an SMS setup and I know little about SMS but this I
> know
> >>> isn't working.  In the storage class ACS routines is this snippet -
> >>>
> >>>  IF &DSN(1) = 'DB2E' THEN
> >>>   DO
> >>> IF &DSN(2) = 'DSNDBC' THEN
> >>>   DO
> >>> SET &STORCLAS='SCDB2'
> >>>   END
> >>> IF &DSN(2) = 'DSNDBD' THEN
> >>>   DO
> >>> SET &STORCLAS='SCDB2'
> >>>   END
> >>>   END
> >>> followed by this -
> >>>
> >>> SELECT
> >>> WHEN (&DSN = &DB2E)
> >>>   SET &STORCLAS = 'SCSMS'
> >>> Question.  Any dataset of the form DB2E.DSNDBC.** is getting the
> storage
> >>> class SCSMS and not SCDB2 which is what is required.  I want all
> >>> DB2E.DSNDBC.** datasets to get SCDB2 and any other DB2E.** dataset
> to get
> >>> SCSMS.  What is wrong with the above syntax please.
> >>>
> >>> Jim McAlpine
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> This e-mail message and all attachments transmitted with it may
> >>> contain legally privileged and/or confidential information intended
> >>> solely for the use of the addressee(s). If the reader of this
> >>> message is not the intended recipient, you are hereby notified that
> >>> any reading, dissemination, distribution, copying, forwarding or
> >>> other use of this message or its attachments is strictly
> >>> prohibited. If you have received this message in error, please
> >>> notify the sender immediately and delete this message and all
> >>> copies and backups thereof. Thank you.
> >>>
> >>> ---
> ---
> >>> 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
>

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[Martin Packer]

I think it would also make job cloning easier.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   zMan 
To: IBM-MAIN@listserv.ua.edu, 
Date:   02/08/2013 02:29 PM
Subject:Re: Rejoice! z/OS 2.1 addresses some long term JCL 
complaints from here:
Sent by:IBM Mainframe Discussion List 



So I've read the PDF but I'm still not clear on this:
Does the enhanced symbol support mean that you can use symbols in places
like this:
REPRO INFILE(GIMZPOOL) +
 OUTDATASET(&HLQ..GLOBAL.CSI)

? That would sure make distributed SMP/E JCL easier for customers to 
modify.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN








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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[zMan]

So I've read the PDF but I'm still not clear on this:
Does the enhanced symbol support mean that you can use symbols in places
like this:
REPRO INFILE(GIMZPOOL) +
 OUTDATASET(&HLQ..GLOBAL.CSI)

? That would sure make distributed SMP/E JCL easier for customers to modify.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: At Last (z/os v2.1) !

[Mark Zelden]

On Fri, 8 Feb 2013 08:22:24 -0500, Don Williams  wrote:

>Over the years, I've asked several times.
>I've wanted in sequence concatenation (since the first time I processed SMF
>data).
>

We've all wanted this "forever".  Better late than never!   

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS v2.1 preview

[Dana Mitchell]

On Thu, 7 Feb 2013 23:36:53 -0600, Jim Elliott, IBM  
wrote:

>Re the 3270 support.
>
>This has been in the HMC for a long time and is used by z/VM. z/OS is finally 
>getting the same support (in addition to the line mode HMC console). So any 
>machine supported by z/OS 2.1 (i.e z9 and later) will have access to 3270 on 
>the HMC.
>

Very good!  How will it be represented in CONSOLxx member?  Using   
DEVNUM(SYSCONS)  perhaps?

Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Opinion: Why it is better to "log" to a UNIX file than a sequential data set.

[John McKown]

Would be neat, but I can't figure out how to have an application write to
the UNIX syslogd daemon simply by using a DD and the UNIX file via QSAM
interface. Hum, I guess it might be possible to use the GPSAM routines on
the CBTTape to do this.


On Fri, Feb 8, 2013 at 7:53 AM, Kirk Wolf  wrote:

> Also consider syslogd, especially for logging of "system" functions.
> This allows you to categorize, filter, and direct logs to unix files that
> are automatically archived to z/OS datasets.
> More info can be found in the Comm Server doc.
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Wed, Feb 6, 2013 at 1:56 PM, John McKown  >wrote:
>
> > This is just my opinion. Others may, and likely will, disagree. But just
> > today, I came up with a reason to "log" to a UNIX file instead of a
> SYSOUT
> > or z/OS sequential data set, and especially the latter.
> >
> > There are many pluses of SYSOUT or UNIX over a sequential data set.
> First,
> > you don't need to specify a SPACE= parameter. Second, unless you use an
> > existing sequential data set and use DISP=SHR, you can't see the output
> as
> > it is being generated. With SYSOUT, you can view it via SDSF. With a UNIX
> > file, you can use ISPF browse or perhaps even the "tail" command on a
> UNIX
> > shell session. The "tail" is nice because you can get to the bottom
> rather
> > quickly.
> >
> > One major plus of a UNIX file over SYSOUT is if you have multiple "log"
> DDs
> > in the same step and you'd like the output to be interspersed. This
> > occurred to me because CA-Endevor enables multiple different traces by
> > using multiple different DD names. Suppose you'd like a consolidated log
> in
> > which each line was in close proximity to the other trace lines generated
> > around the same time. I cannot think of a way to do this with either
> SYSOUT
> > or a sequential data set. Perhaps I'm missing something.
> >
> > But for the above, in UNIX, you can easily do:
> >
> > // SET LOGFILE='/tmp/&SYSUID..this.trace'
> > //* OTHER JCL
> > //* TRACE DDS
> > //EN$TRALC DD PATH='&LOGFILE',
> > // PATHOPTS=(OWRONLY,OAPPEND,OCREAT),
> > // PATHDISP=(KEEP,KEEP)
> > // RECFM=FA,LRECL=133,BLKSIZE=133
> > //*
> > //EN$TRITE DD PATH='&LOGFILE',
> > // PATHOPTS=(OWRONLY,OAPPEND,OCREAT),
> > // PATHDISP=(KEEP,KEEP)
> > // RECFM=FA,LRECL=133,BLKSIZE=133
> > //*
> > //* AND SO ON.
> > //*
> >
> > Because I specified "unblocked" output, each line is written to the file
> > immediately (OK, put in
> > the UNIX kernel's buffer for the file). The OAPPEND on each means that
> > every write operation is
> > prefixed with a "go to the end of the file" type operation. Since the
> > buffering for a given specific UNIX file is kept in a single file buffer
> in
> > the kernel, this means that the lines should be written to the in pretty
> > much time sequenced order.
> >
> > Hope this is at least of some interest.
> >
> > --
> > This is a test of the Emergency Broadcast System. If this had been an
> > actual emergency, do you really think we'd stick around to tell you?
> >
> > Maranatha! <><
> > John McKown
> >
> > --
> > 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
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:

[Paul Gilmartin]

On Fri, 8 Feb 2013 00:36:54 -0600, Tom Wasik wrote:

>If you are interested, there is some additional detail on the 2.1 JES2 JCL 
>changes in my SHARE pitch from this week:
>http://share.confex.com/share/120/webprogram/Handout/Session13029/JES2%20Product%20Update%20and%20Latest%20Status.pdf
> 
Mentions:

o System Symbol Substitution in BATCH Jobs
• Any system symbol (IEASYMxx) can be referred to in JCL
• JOBLCASS SYSSYM=ALLOW|DISALLOW option 
• Substitution occurs at conversion time

At last?

o Symbolic Substitution in Instream Data Sets
•   SYMBOLS= keyword on DD DATA or DD * JCL
SYMBOLS=[ ( ] JCLONLY | EXECSYS | CNVTSYS [ , DDname])
•   Substitution as records are read by application

May I assume this means the value of symbols in the context of
the EXEC statement?

•   Blank elimination to try to make things fit •   Overflow if possible, 
I/O error if not

Embedded blanks, or only trailing?
Will this affect the LRECL of a RECFM=VB instream data set?

o Passing Symbols on INTRDR
• SYMLIST= keyword identifies symbols to pass

Will this be a keyword supported by TSO ALLOCATE and BPXWDYN,
presumably as a TU for SVC 99?

No mention of long PARM or PARMDD?

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SFTP vs. FTPS (was: z/OS v2.1 preview)

[Kirk Wolf]

On Thu, Feb 7, 2013 at 7:15 PM, Paul Gilmartin  wrote:

> On Thu, 7 Feb 2013 14:20:02 -0600, Kirk Wolf wrote:
>
> >Walt,
> >
> >You are correct - FTP is more prevalent in z/OS shops.
> >
> >SFTP is much more prevalent in distributed systems since OpenSSH is
> >installed as a default package on all modern Unix/Linux distros.   Also,
> >SSH/SFTP uses a single port/connection which has significant advantages
> >when it comes to navigating modern networks.
> >
> Did you intend to disqualify OMVS as a "modern Unix/Linux distro"?
>
>
(Sorry if my sarcasm detector isn't working for your post, but) yeah -
z/OS is not a Unix/Linux distro :-)   z/OS Unix isn't either - its a POSIX
layer for z/OS.

Also, a Unix system isn't complete without the full GNU suite, IMO.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Opinion: Why it is better to "log" to a UNIX file than a sequential data set.

[Kirk Wolf]

Also consider syslogd, especially for logging of "system" functions.
This allows you to categorize, filter, and direct logs to unix files that
are automatically archived to z/OS datasets.
More info can be found in the Comm Server doc.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, Feb 6, 2013 at 1:56 PM, John McKown wrote:

> This is just my opinion. Others may, and likely will, disagree. But just
> today, I came up with a reason to "log" to a UNIX file instead of a SYSOUT
> or z/OS sequential data set, and especially the latter.
>
> There are many pluses of SYSOUT or UNIX over a sequential data set. First,
> you don't need to specify a SPACE= parameter. Second, unless you use an
> existing sequential data set and use DISP=SHR, you can't see the output as
> it is being generated. With SYSOUT, you can view it via SDSF. With a UNIX
> file, you can use ISPF browse or perhaps even the "tail" command on a UNIX
> shell session. The "tail" is nice because you can get to the bottom rather
> quickly.
>
> One major plus of a UNIX file over SYSOUT is if you have multiple "log" DDs
> in the same step and you'd like the output to be interspersed. This
> occurred to me because CA-Endevor enables multiple different traces by
> using multiple different DD names. Suppose you'd like a consolidated log in
> which each line was in close proximity to the other trace lines generated
> around the same time. I cannot think of a way to do this with either SYSOUT
> or a sequential data set. Perhaps I'm missing something.
>
> But for the above, in UNIX, you can easily do:
>
> // SET LOGFILE='/tmp/&SYSUID..this.trace'
> //* OTHER JCL
> //* TRACE DDS
> //EN$TRALC DD PATH='&LOGFILE',
> // PATHOPTS=(OWRONLY,OAPPEND,OCREAT),
> // PATHDISP=(KEEP,KEEP)
> // RECFM=FA,LRECL=133,BLKSIZE=133
> //*
> //EN$TRITE DD PATH='&LOGFILE',
> // PATHOPTS=(OWRONLY,OAPPEND,OCREAT),
> // PATHDISP=(KEEP,KEEP)
> // RECFM=FA,LRECL=133,BLKSIZE=133
> //*
> //* AND SO ON.
> //*
>
> Because I specified "unblocked" output, each line is written to the file
> immediately (OK, put in
> the UNIX kernel's buffer for the file). The OAPPEND on each means that
> every write operation is
> prefixed with a "go to the end of the file" type operation. Since the
> buffering for a given specific UNIX file is kept in a single file buffer in
> the kernel, this means that the lines should be written to the in pretty
> much time sequenced order.
>
> Hope this is at least of some interest.
>
> --
> This is a test of the Emergency Broadcast System. If this had been an
> actual emergency, do you really think we'd stick around to tell you?
>
> Maranatha! <><
> John McKown
>
> --
> 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: At Last (z/os v2.1) !

[Don Williams]

Over the years, I've asked several times.
I've wanted in sequence concatentation (since the first time I processed SMF
data).

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Frank Swarbrick
> Sent: Thursday, February 07, 2013 6:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: At Last (z/os v2.1) !
> 
> Excellent!  Another thing I've wanted and figured it was fruitless to
> ask for.
> I wonder what prompted all of these nice enhancements after so long.
> 
> 
> 
> >
> > From: Ed Gould 
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Sent: Tuesday, February 5, 2013 10:59 PM
> >Subject: At Last (z/os v2.1) !
> >
> >In z/OS V2.1, z/OS DFSMS and Allocation processing are planned to be
> enhanced to allow you to specify that all the members of a generation
> data group (GDG) be returned in order from oldest to newest when the
> generation data set (GDS) name is specified without a generation
> number. This is intended to allow all the members of a GDG to be
> processed in chronological order without being sorted.
> >
> >--
> >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: basic SMS question

[Vernooij, CP - SPLXM]

Correct, very irritating restriction.
You can MOVE the dataset with DFDSS and provide a new DATACLAS then.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Brian Fraser
Sent: Friday, February 08, 2013 13:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: basic SMS question

>>ALTER data.set.name DATACLAS(newvalue)

DATACLAS is not an optional parameter to IDCAMS ALTER

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: basic SMS question

[Brian Fraser]

>>ALTER data.set.name DATACLAS(newvalue)

DATACLAS is not an optional parameter to IDCAMS ALTER

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: basic SMS question

[Jim McAlpine]

Thanks Mike.

Jim

On Fri, Feb 8, 2013 at 11:35 AM, Mike Schwab wrote:

> ALTER data.set.name DATACLAS(newvalue)
> On a ISPF 3.4 line, a / picks up the data.set.name from that line.
>
> On Fri, Feb 8, 2013 at 3:15 AM, Jim McAlpine 
> wrote:
> > I've found another error in the data class selection routines which means
> > that datasets have been converted but not assigned the correct data
> class.
> > What is the quickest way to reassign a data class (or storage class come
> to
> > that).  Do I have to CONVERTV to NONSMS and then CONVERTV to SMS again or
> > is there some quicker method.
> >
> > Jim McAlpine
> >
> > On Thu, Feb 7, 2013 at 4:11 PM, Jim McAlpine 
> wrote:
> >
> >> Thanks for the explanation.  Much appreciated.
> >>
> >> Jim McAlpine
> >>
> >>  On Thu, Feb 7, 2013 at 3:51 PM, Darth Keller <
> darth.kel...@assurant.com>wrote:
> >>
> >>> A couple of things -
> >>>
> >>> &DSN(2) = 'DSNDBD'   -  'DSNDBD' in the 2nd level generally
> identifies
> >>> the data component of a DB2 LDS.  Data components do not get assigned
> >>> their own SMS Constructs.  Constructs are assigned at the cluster
> level. I
> >>> see this as useless code unless your shop is actually using cluster
> names
> >>> with DSNDBD as the 2nd level.
> >>>
> >>> 2ndly - the answer to your question is going to depend on what's in the
> >>> filterlist &DB2E.
> >>>
> >>> If it contains an entry like DB2E.**   , then all those datasets
> would
> >>> be assigned SCDB2 in the &DSN(1) segment and then re-assigned SCSMS in
> the
> >>> SELECT/WHEN you've shown us.   This is a result of not having a EXIT in
> >>> the first set of statements - the allocation falls through into the
> next
> >>> code segment and gets re-evaluated.  And it will continue to be
> >>> re-evaluated after your
> >>> SET &STORCLAS = 'SCSMS'as that statement also doesn't appear to
> have a
> >>> paired EXIT.
> >>>
> >>> Without the WRITE stmts Lisa mentioned, it's pretty hard to tell from
> what
> >>> you've shown us.  Your allocation could actually have several storage
> >>> classes assigned and re-assigned, with some other segment having the
> final
> >>> assignment of 'SCSMS' before it finally falls out of SMS.
> >>>
> >>> My general rule of thumb is that the only time I don't pair a SET with
> an
> >>> EXIT is when I want to set a default StorCLas.  I always pair a SET
> with a
> >>> WRITE and generally its a SET, WRITE, & EXIT.
> >>>
> >>> I'd recommend investigating NAVIQUEST to use in testing your code & any
> >>> changes you're thinking of making.
> >>> ddk
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>> I've inherited an SMS setup and I know little about SMS but this I know
> >>> isn't working.  In the storage class ACS routines is this snippet -
> >>>
> >>>  IF &DSN(1) = 'DB2E' THEN
> >>>   DO
> >>> IF &DSN(2) = 'DSNDBC' THEN
> >>>   DO
> >>> SET &STORCLAS='SCDB2'
> >>>   END
> >>> IF &DSN(2) = 'DSNDBD' THEN
> >>>   DO
> >>> SET &STORCLAS='SCDB2'
> >>>   END
> >>>   END
> >>> followed by this -
> >>>
> >>> SELECT
> >>> WHEN (&DSN = &DB2E)
> >>>   SET &STORCLAS = 'SCSMS'
> >>> Question.  Any dataset of the form DB2E.DSNDBC.** is getting the
> storage
> >>> class SCSMS and not SCDB2 which is what is required.  I want all
> >>> DB2E.DSNDBC.** datasets to get SCDB2 and any other DB2E.** dataset to
> get
> >>> SCSMS.  What is wrong with the above syntax please.
> >>>
> >>> Jim McAlpine
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> This e-mail message and all attachments transmitted with it may
> >>> contain legally privileged and/or confidential information intended
> >>> solely for the use of the addressee(s). If the reader of this
> >>> message is not the intended recipient, you are hereby notified that
> >>> any reading, dissemination, distribution, copying, forwarding or
> >>> other use of this message or its attachments is strictly
> >>> prohibited. If you have received this message in error, please
> >>> notify the sender immediately and delete this message and all
> >>> copies and backups thereof. Thank you.
> >>>
> >>> --
> >>> 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 / archi

Re: basic SMS question

[Mike Schwab]

ALTER data.set.name DATACLAS(newvalue)
On a ISPF 3.4 line, a / picks up the data.set.name from that line.

On Fri, Feb 8, 2013 at 3:15 AM, Jim McAlpine  wrote:
> I've found another error in the data class selection routines which means
> that datasets have been converted but not assigned the correct data class.
> What is the quickest way to reassign a data class (or storage class come to
> that).  Do I have to CONVERTV to NONSMS and then CONVERTV to SMS again or
> is there some quicker method.
>
> Jim McAlpine
>
> On Thu, Feb 7, 2013 at 4:11 PM, Jim McAlpine  wrote:
>
>> Thanks for the explanation.  Much appreciated.
>>
>> Jim McAlpine
>>
>>  On Thu, Feb 7, 2013 at 3:51 PM, Darth Keller 
>> wrote:
>>
>>> A couple of things -
>>>
>>> &DSN(2) = 'DSNDBD'   -  'DSNDBD' in the 2nd level generally identifies
>>> the data component of a DB2 LDS.  Data components do not get assigned
>>> their own SMS Constructs.  Constructs are assigned at the cluster level. I
>>> see this as useless code unless your shop is actually using cluster names
>>> with DSNDBD as the 2nd level.
>>>
>>> 2ndly - the answer to your question is going to depend on what's in the
>>> filterlist &DB2E.
>>>
>>> If it contains an entry like DB2E.**   , then all those datasets would
>>> be assigned SCDB2 in the &DSN(1) segment and then re-assigned SCSMS in the
>>> SELECT/WHEN you've shown us.   This is a result of not having a EXIT in
>>> the first set of statements - the allocation falls through into the next
>>> code segment and gets re-evaluated.  And it will continue to be
>>> re-evaluated after your
>>> SET &STORCLAS = 'SCSMS'as that statement also doesn't appear to have a
>>> paired EXIT.
>>>
>>> Without the WRITE stmts Lisa mentioned, it's pretty hard to tell from what
>>> you've shown us.  Your allocation could actually have several storage
>>> classes assigned and re-assigned, with some other segment having the final
>>> assignment of 'SCSMS' before it finally falls out of SMS.
>>>
>>> My general rule of thumb is that the only time I don't pair a SET with an
>>> EXIT is when I want to set a default StorCLas.  I always pair a SET with a
>>> WRITE and generally its a SET, WRITE, & EXIT.
>>>
>>> I'd recommend investigating NAVIQUEST to use in testing your code & any
>>> changes you're thinking of making.
>>> ddk
>>>
>>>
>>> 
>>>
>>>
>>> I've inherited an SMS setup and I know little about SMS but this I know
>>> isn't working.  In the storage class ACS routines is this snippet -
>>>
>>>  IF &DSN(1) = 'DB2E' THEN
>>>   DO
>>> IF &DSN(2) = 'DSNDBC' THEN
>>>   DO
>>> SET &STORCLAS='SCDB2'
>>>   END
>>> IF &DSN(2) = 'DSNDBD' THEN
>>>   DO
>>> SET &STORCLAS='SCDB2'
>>>   END
>>>   END
>>> followed by this -
>>>
>>> SELECT
>>> WHEN (&DSN = &DB2E)
>>>   SET &STORCLAS = 'SCSMS'
>>> Question.  Any dataset of the form DB2E.DSNDBC.** is getting the storage
>>> class SCSMS and not SCDB2 which is what is required.  I want all
>>> DB2E.DSNDBC.** datasets to get SCDB2 and any other DB2E.** dataset to get
>>> SCSMS.  What is wrong with the above syntax please.
>>>
>>> Jim McAlpine
>>>
>>>
>>>
>>>
>>>
>>> This e-mail message and all attachments transmitted with it may
>>> contain legally privileged and/or confidential information intended
>>> solely for the use of the addressee(s). If the reader of this
>>> message is not the intended recipient, you are hereby notified that
>>> any reading, dissemination, distribution, copying, forwarding or
>>> other use of this message or its attachments is strictly
>>> prohibited. If you have received this message in error, please
>>> notify the sender immediately and delete this message and all
>>> copies and backups thereof. Thank you.
>>>
>>> --
>>> 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: z/OS v2.1 preview

[Elardus Engelbrecht]

Martin Packer wrote:

>Disclaimer: I'm not a product developer and nobody has to listen to me. :-)

Yes, zChampion, at this moment I'm not listening to you, but am *forced* to 
read your mails... ;-D

Thanks for your post. Most interesting thread, anyway.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JES2 Hist from Jack Schudel(ret.)

[David Devine]

Historically "Spool" has had a long association with the weaving/rope making 
industry and thence to wire cable & electrical wiring.

Possibly the imagery of how an industrial weaving loom worked fitted in with 
the concept of what was trying to be achieved and last but not least it may 
well have been developed in Ibm SPOKANE and the guys there wanted to put their 
own stamp on it and were looking for an SPO prefix that matched up.
   
After all, DFH = Denver Foot Hills. IDC = International Data Corporation.

What better way to be remembered if you aren't allowed to stick your personal 
name on it.

And for another bit of history, paper tape/punched cards were used in 
industrial weaving looms back in the late 1800's to mass produce carpet and 
other fabrics to the same design & quality.

As of a few years ago, there was at least one working "museum" weaving shop in 
the UK midlands where it could be seen in action, about a 100 yard loop of 
heavy duty punched card.

Regards,
 Dave

***
In <51143860.7030...@acm.org>, on 02/07/2013
   at 05:27 PM, "Joel C. Ewing"  said:

>The Wood history of HASP/JES2 left hanging the question about the
>origin of the term "spooling". 

Do you consider SPOOL System, 7070-IO-076 to be of sufficient
antiquity?

'"SPOOL" has become a common verb, but originally was itself an
acronym signifying Simultaneous Peripheral Operations On Line. This
acronym originated with the 7070 computer, which had a system of
interrupts that let one program a peripheral activity (e.g.,
card-to-tape, tape-to-print, tape-to-card) while a main program was
running.' (Dictionary of IBM Jargon, Tenth Edition)

>Since early "spooling" systems staged unit records  to a spool of 
>magnetic tape,

I've only seen reels of tape called spools in an audio or TV context;
prior to cartridges and MSS the terms I heard were "reel" and "tape
volume".

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: basic SMS question

[Jim McAlpine]

I've found another error in the data class selection routines which means
that datasets have been converted but not assigned the correct data class.
What is the quickest way to reassign a data class (or storage class come to
that).  Do I have to CONVERTV to NONSMS and then CONVERTV to SMS again or
is there some quicker method.

Jim McAlpine

On Thu, Feb 7, 2013 at 4:11 PM, Jim McAlpine  wrote:

> Thanks for the explanation.  Much appreciated.
>
> Jim McAlpine
>
>  On Thu, Feb 7, 2013 at 3:51 PM, Darth Keller 
> wrote:
>
>> A couple of things -
>>
>> &DSN(2) = 'DSNDBD'   -  'DSNDBD' in the 2nd level generally identifies
>> the data component of a DB2 LDS.  Data components do not get assigned
>> their own SMS Constructs.  Constructs are assigned at the cluster level. I
>> see this as useless code unless your shop is actually using cluster names
>> with DSNDBD as the 2nd level.
>>
>> 2ndly - the answer to your question is going to depend on what's in the
>> filterlist &DB2E.
>>
>> If it contains an entry like DB2E.**   , then all those datasets would
>> be assigned SCDB2 in the &DSN(1) segment and then re-assigned SCSMS in the
>> SELECT/WHEN you've shown us.   This is a result of not having a EXIT in
>> the first set of statements - the allocation falls through into the next
>> code segment and gets re-evaluated.  And it will continue to be
>> re-evaluated after your
>> SET &STORCLAS = 'SCSMS'as that statement also doesn't appear to have a
>> paired EXIT.
>>
>> Without the WRITE stmts Lisa mentioned, it's pretty hard to tell from what
>> you've shown us.  Your allocation could actually have several storage
>> classes assigned and re-assigned, with some other segment having the final
>> assignment of 'SCSMS' before it finally falls out of SMS.
>>
>> My general rule of thumb is that the only time I don't pair a SET with an
>> EXIT is when I want to set a default StorCLas.  I always pair a SET with a
>> WRITE and generally its a SET, WRITE, & EXIT.
>>
>> I'd recommend investigating NAVIQUEST to use in testing your code & any
>> changes you're thinking of making.
>> ddk
>>
>>
>> 
>>
>>
>> I've inherited an SMS setup and I know little about SMS but this I know
>> isn't working.  In the storage class ACS routines is this snippet -
>>
>>  IF &DSN(1) = 'DB2E' THEN
>>   DO
>> IF &DSN(2) = 'DSNDBC' THEN
>>   DO
>> SET &STORCLAS='SCDB2'
>>   END
>> IF &DSN(2) = 'DSNDBD' THEN
>>   DO
>> SET &STORCLAS='SCDB2'
>>   END
>>   END
>> followed by this -
>>
>> SELECT
>> WHEN (&DSN = &DB2E)
>>   SET &STORCLAS = 'SCSMS'
>> Question.  Any dataset of the form DB2E.DSNDBC.** is getting the storage
>> class SCSMS and not SCDB2 which is what is required.  I want all
>> DB2E.DSNDBC.** datasets to get SCDB2 and any other DB2E.** dataset to get
>> SCSMS.  What is wrong with the above syntax please.
>>
>> Jim McAlpine
>>
>>
>>
>>
>>
>> This e-mail message and all attachments transmitted with it may
>> contain legally privileged and/or confidential information intended
>> solely for the use of the addressee(s). If the reader of this
>> message is not the intended recipient, you are hereby notified that
>> any reading, dissemination, distribution, copying, forwarding or
>> other use of this message or its attachments is strictly
>> prohibited. If you have received this message in error, please
>> notify the sender immediately and delete this message and all
>> copies and backups thereof. Thank you.
>>
>> --
>> 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: z/OS v2.1 preview

[Martin Packer]

Do you know if this is the "standard" RegExp functions callable from C 
that are driving this? I've advised various developers that if z/OS 
product functions standardise on using these we:

1) All know what to expect - and the skills are interchangeable from tool 
to tool.

2) Can beat up on the one development team for any enhancements that might 
be needed.

Disclaimer: I'm not a product developer and nobody has to listen to me. 
:-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Mark Zelden 
To: IBM-MAIN@listserv.ua.edu, 
Date:   02/07/2013 10:58 PM
Subject:Re: z/OS v2.1 preview
Sent by:IBM Mainframe Discussion List 



I just downloaded a current  version of SPFlist  (was running 4.3, current 
is 6.1)
and found out is supports regular expressions now.   http://spflite.co.nr/

I don't know what ISPF's implementation will be like, but for SPFLite
you use FIND R'regular expression'. 

So I can play with this now.  :-) 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS 
mailto:m...@mzelden.com 
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/



On Tue, 5 Feb 2013 20:23:48 +, Martin Packer 
 wrote:

>I think you're going to like them, Mark. Not that I've found a system to
>play with this on yet.
>
>Cheers, Martin
>
>Martin Packer,
>zChampion, Principal Systems Investigator,
>Worldwide Banking Center of Excellence, IBM
>
>+44-7802-245-584
>
>email: martin_pac...@uk.ibm.com
>
>Twitter / Facebook IDs: MartinPacker
>Blog:
>https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
>
>
>From:   Mark Zelden 
>To: IBM-MAIN@listserv.ua.edu,
>Date:   02/05/2013 07:48 PM
>Subject:Re: z/OS v2.1 preview
>Sent by:IBM Mainframe Discussion List 
>
>
>
>I know of at least a few people on this list that will love this one:
>
>  "The ISPF editor is planned to allow regular expressions to be 
specified
>as
>  arguments to the FIND and CHANGE commands. "
>
>I've even used Doug Nadel's FINDRX macro a few times, but admit I still
>don't really "get" regular expressions (I'm sure if I used *nix more
> I would).
>
>
>--
>Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
>mailto:m...@mzelden.com
>Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
>Systems Programming expert at http://expertanswercenter.techtarget.com/
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
>
>
>
>
>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...@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








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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS v2.1 preview

[Timothy Sipples]

Re: FTPS v. SFTP, there are pros and cons to almost everything in IT. One
more "pro" with FTPS is that many customers have implemented FTP already in
various operationally complex ways -- scripts, exits, monitors, whatever,
whatever. Flipping on the TLS/SSL "switch" changes little if anything that
way, and we all know that avoiding breakage is a good instinct to have.

I'm also told that security geeks tend to prefer FTPS if they have a
choice, at least when "discussing" such things in the back halls of
security conferences. And FTPS has the option to encrypt the control
channel but leave the transport channel unencrypted to ease the crypto
burden for those who are (overly?) sensitive to such things. I don't know
whether IBM will even offer that option, but for servicing an operating
system that makes sense in the abstract. You definitely want to make sure
what you're getting is authentic and verified as coming from IBM and from
no one else, you want your own access credentials kept confidential, and
you want payloads tested for authenticity, integrity, and fidelity. But you
probably don't particularly care if someone else also sees that multi-site
distributed code en route.

That said, if you don't like FTPS, it isn't the only option. IBM also
offers a path called Download Director for z/OS servicing. And of course
SFTP is fully supported on z/OS for other purposes.


Timothy Sipples
Consulting Enterprise IT Architect (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN