Re: Binder MODULE map for UNIX files

[Ravi Gaur]

Not sure but does it has to do with concatenation ? 

The binder does not support z/OS UNIX files concatenated with other z/OS UNIX 
files or data sets of any type.

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

Re: SLIP trap or some other possibility to DUMP on a given message text ?

[Ravi Gaur]

This is one example where if Register 5 (Dataset name ) match the ICH408I it 
will capture Svcdump.

slip set,enable,id=rk01,msgid=ich408i,jobname=NBKEODV,   
Action=svcd,matchlim=1,data=(5R,EQC,SYS1.TCPPARMS),DEBUG,END 

  ICH408I USER(NBKEODV ) GROUP(AL3ZOS  ) NAME(KUMAR, RAVI ) 725 
SYS1.TCPPARMS CL(DATASET ) VOL(9T1SL2)  
INSUFFICIENT ACCESS AUTHORITY   
FROM SYS1.TCPPARMS (G)  
ACCESS INTENT(UPDATE )  ACCESS ALLOWED(READ   ) 
  IEC150I 913-38,IFG0194E,NBKEODV,TSOPNB00,ISP01108,2173,9T1SL2,SYS1.TCPPA  
  RMS   
 *044 IEA793A NO DUMP DATA SETS AVAILABLE FOR DUMPID=004 BY JOB (NBKEODV

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

Re: syslogd: FSUM1229 syslogd is already active

[Ravi Gaur]

Did you check if really SYSLOGD address space active or not? it capture log for 
FTP daemon etc..

D A,SYSLOGD 
IEE115I 01.08.26 2012.286 ACTIVITY 488  
 JOBS M/STS USERSSYSASINITS   ACTIVE/MAX VTAM OAS   
3000181  00033001851/00100   00015  
 SYSLOGD  STEP1OMVSKERN NSW  AO  A=00E3   PER=NO   SMC=000  
 PGN=N/A  DMN=N/A  AFF=NONE 
 CT=002.146S  ET=00110.13   
 WUID=STC18964 USERID=OMVSKERN  
 WKL=STC  SCL=STCMDP=1  
 RGP=N/A  SRVR=NO  QSC=NO   
 ADDR SPACE ASTE=3EE768C0  

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

Re: how do you answer the "My job is too important to follow normal channels for help" statement?

[Scott Ford]

There is a name for a manager like that 

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 Oct 11, 2012, at 6:03 PM, Phil Smith III  wrote:

> ObAnecdote: 
> 
> 
> 
> A long time ago (17 years), the small software company where I worked was
> finally connected to the nascent Internet, at a blazing 9600bps. We had a
> tiny web server running on (then) VM/ESA, serving a static page.
> 
> 
> 
> The Senior VP of Marketing came by my office and asked if I knew how to fix
> DNS so it would point to the shiny new corporate page he had just spent a
> gazillion bucks on. "Sure", sez I, since I'd set up DNS on VM. (I think we
> were the ONLY site on the planet running a VM DNS as a primary pulling from
> a secondary, based on the bugs we found and the IBM developer-level support
> it required to get it working! But I digress.)
> 
> 
> 
> The nominal data center manager was a guy who'd fallen into the position
> because the previous one quit, after being told that a long-scheduled,
> expensive vacation had to be postponed with no notice and no recompense
> because his boss wanted him to do something. And he was out of town (this
> was pre-cellphone etc.). Besides, what was he going to do, argue with the
> Sr. VP? So I fixed the DNS and sent him a note, telling him exactly what I
> changed and saying "The Senior VP wanted this fixed, so I did it."
> 
> 
> 
> When he got back, he had a hissy fit about it and yanked all my system
> privileges. I went to our mutual boss, who called him over, and the
> conversation went like a bad movie:
> 
> 
> 
> "Put back Phil's privileges."
> 
> "No. He shouldn't have done that without my permission."
> 
> "You weren't available. Put 'em back."
> 
> "No. I'll walk out this door before I do that."
> 
> "OK.bye!"
> 
> 
> 
> And that was that. He was gone. So now I had to do his job, too, but at
> least I didn't have to deal with his psychosis!
> 
> 
> --
> 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

Query for Destination z article on chargeback systems

[Gabe Goldberg]

Query for Destination z article on chargeback systems

I'm writing article for Destination z -- http://destinationz.org/ -- 
giving tips on chargeback systems. I'm interested in reasons for/against 
implementing chargeback; technical tips for implementing; political 
hints for inflicting, including getting management buy-in; financial 
aspects for setting fair rates; suggestions for DEFINING fair rates; 
native tools, vendor and free offerings, home-grown systems; 
problems/pitfalls/gotchas/solutions; reality matters for preventing 
mainframes from being burdened with unrelated costs and overheads; etc.


For this one, brief anecdotes -- war/horror stories describing 
good/bad/neutral experiences -- will be useful. I'll review list 
archives but pointers to relevant threads will help.


Operating system-agnostic tips and system-specific issues/tips/tools are 
both essential.


As usual, please copy me directly so I don't miss responses in list 
digests. Thanks...


--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0

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

Getting keyword in a verify exit

[micheal butz]

Hi,

I am using a  the same VALIDCK exit when processing 2 different 
subfields


Is there anyway to determine what the corresponding keyword would be in 
the exit



Is there anyway to know what the corresponding subfiled e.g.

where member is the keyword

 MEMBER(SOURCE)

 ANd I am processing the subfield source in a "VALIDCK=" exit

Thanks

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

Re: DFHSM Recalls and Tape

[Robert A. Rosenberg]

At 11:55 + on 10/11/2012, Hervey Martinez wrote about Re: DFHSM 
Recalls and Tape:


If you have CRQ(Common Recall Queue) set up, then HSM will "look 
ahead" and recall all files that are on the same tape. Also, with 
CRQ, you can limit which LPARS will perform recalls and limit them 
in that manner and all recalls will be routed to that LPAR. 
Otherwise, the recalls happen one at a time in a FIFO manner.


Regards,

Hervey


Thank You. Looks like CRQ is the right way to go since it insures 
that once a tape has been mounted, it will be used to restore all the 
files on that tape before moving on to another tape. I can see that 
this has a downside since a high priority recall can be postponed 
since it is coming from a different tape (a situation that might not 
occur with a FIFO if there was the ability to insert the request at 
the top of the queue). You note that CRQ can restrict which LPAR does 
the recall. Can it be set to allow more than one LPAR to run the 
recalls (each with its only tape volume to process).


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

Re: DFHSM Recalls and Tape

[Robert A. Rosenberg]

At 10:10 -0400 on 10/11/2012, O'Brien, David W. (NIH/CIT) [C] wrote 
about Re: DFHSM Recalls and Tape:



Elardus,

I think you missed the distinction between submitting recalls and a 
process causing recalls. At this shop it was not unusual for a user 
to submit an Iefbr14 job to delete datasets thereby causing the 
recall of any dataset that had been migrated. Since the recall is 
serial, it would result in one tape mount per recall.


Dave O'Brien


Use of a DEFER in the JCL should (if I remember correctly) bypass the 
need for the recall and go direct to the uncatalog [which does not 
need a recall].


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

Re: how do you answer the "My job is too important to follow normal channels for help" statement?

[Phil Smith III]

ObAnecdote: 

 

A long time ago (17 years), the small software company where I worked was
finally connected to the nascent Internet, at a blazing 9600bps. We had a
tiny web server running on (then) VM/ESA, serving a static page.

 

The Senior VP of Marketing came by my office and asked if I knew how to fix
DNS so it would point to the shiny new corporate page he had just spent a
gazillion bucks on. "Sure", sez I, since I'd set up DNS on VM. (I think we
were the ONLY site on the planet running a VM DNS as a primary pulling from
a secondary, based on the bugs we found and the IBM developer-level support
it required to get it working! But I digress.)

 

The nominal data center manager was a guy who'd fallen into the position
because the previous one quit, after being told that a long-scheduled,
expensive vacation had to be postponed with no notice and no recompense
because his boss wanted him to do something. And he was out of town (this
was pre-cellphone etc.). Besides, what was he going to do, argue with the
Sr. VP? So I fixed the DNS and sent him a note, telling him exactly what I
changed and saying "The Senior VP wanted this fixed, so I did it."

 

When he got back, he had a hissy fit about it and yanked all my system
privileges. I went to our mutual boss, who called him over, and the
conversation went like a bad movie:

 

"Put back Phil's privileges."

"No. He shouldn't have done that without my permission."

"You weren't available. Put 'em back."

"No. I'll walk out this door before I do that."

"OK.bye!"

 

And that was that. He was gone. So now I had to do his job, too, but at
least I didn't have to deal with his psychosis!


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

Re: how do you answer the "My job is too important to follow normal channels for help" statement?

[Grinsell, Don]

Does said person sign your paycheck or are they in some other way in your food 
chain?  If not, then I think you can refer them to the appropriate policy.  If 
so, then I guess Clint Eastwood's question is appropriate:  "Do you feel lucky?"

--
 
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"If 'heaven is the Lord's,' the earth is the inheritance of man, and that 
consequently any honest traveller has the right to walk as he chooses, all over 
that globe which is his."
~ Alexandra David-Neel, My Journey to Lhasa

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

Re: how do you answer the "My job is too important to follow normal channels for help" statement?

[zMan]

On Thu, Oct 11, 2012 at 4:52 PM, Roberts, John J
wrote:

> I think the right response is: Yes, Mr President, I'll get right on this!
>
> Or in earlier times: Yes, My Liege, Your Wish is My Command!


Well, sure, if THAT's the level of request! But then it's a simple matter
of telling your boss, "Mr. Bigwig had me do this". What's (S)HE gonna say?
-- 
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: SMP/E question

[Skip Robinson]

DOC related to message content has its own category: AO . 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   "Shmuel Metz (Seymour J.)" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   10/11/2012 01:44 PM
Subject:Re: SMP/E question
Sent by:IBM Mainframe Discussion List 



In
,
on 10/10/2012
   at 08:36 AM, Skip Robinson  said:

>I've said previously that a DOC record requiring action should be 
>(re)classified (or accompanied by) an ACTION hold.

Typically a DOC hold is there because of new messages; an ACTION hold
for that would be inappropriate. Similarly, if the DOC hold is because
of new function that is off by default the ACTION is again
inappropriate.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2


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

Re: how do you answer the "My job is too important to follow normal channels for help" statement?

[Roberts, John J]

I think the right response is: Yes, Mr President, I'll get right on this!

Or in earlier times: Yes, My Liege, Your Wish is My Command!

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

Re: Zero length records outlawed! (Again.)

[Shmuel Metz (Seymour J.)]

In <2370190418757832.wa.paulgboulderaim@listserv.ua.edu>, on
10/09/2012
   at 04:23 PM, Paul Gilmartin  said:

>I've been told there is a Track Balance system call that tells 
>(used to) how much space remained on a track.

"7.5  Performing Track Calculations" in z/OS DFSMSdfp Advanced
Services, SC26-7400-09.

-- 
 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: SMP/E question

[Shmuel Metz (Seymour J.)]

In
,
on 10/10/2012
   at 08:36 AM, Skip Robinson  said:

>I've said previously that a DOC record requiring action should be 
>(re)classified (or accompanied by) an ACTION hold.

Typically a DOC hold is there because of new messages; an ACTION hold
for that would be inappropriate. Similarly, if the DOC hold is because
of new function that is off by default the ACTION is again
inappropriate.

-- 
 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: Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?

[Shmuel Metz (Seymour J.)]

In
<77142d37c0c3c34da0d7b1da7d7ca34372300...@nwt-s-mbx1.rocketsoftware.com>,
on 10/10/2012
   at 06:35 PM, Bill Fairchild  said:

>Shmuel,  you often attribute malicious intent to other posters when
>you call them hypocritical.

Only when they appear hypocritical.

>I believe your reply to Mr. Gilmore is therefore hypocritical.

You're free to believe what you want to believe, however incorrect.

-- 
 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: Question about Catalogs and VSAM

[Shmuel Metz (Seymour J.)]

In
<5a5d121d7293fe498308f3835183d19413c70...@ch1prd0510mb380.namprd05.prod.outlook.com>,
on 10/10/2012
   at 08:43 PM, Daniel Allen  said:

>We have a SYSPLEX of four LPARs, each LPAR has a separate Master
>Catalog and a separate User Catalog defined to the Master Catalog.

>Each Master Catalog has an alias called JUNK, which is defined to a
>User Catalog.

Why not have uniques names for unique data sets?

>Is this correct ? If so, is there a way to get around it ?

The ENQ done by Allocation is normal behavior, and getting around it
is dangerous. 

-- 
 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: z/OS 1.12 SSHD authentication failing

[Donald J.]

Thanks for response.
It appears the SCEERUN2 XPLINK members were put in MLPA
instead of dynamic LPA (error message at IPL time because of PDS-E).  
The MLS messages were apparently not errors, just misleading 
as to where the problem was.
 
-- 
  Donald J.
  dona...@4email.net


On Wed, Oct 10, 2012, at 12:55 PM, Rob Schramm wrote:
> I think you may be running up against a SERVAUTH or NETACCESS resource
> class setup.
> 
> Any security violations?
> 
> Rob Schramm
> Senior Systems Consultant
> Imperium Group
> 
> 
> 
> 
> On Wed, Oct 10, 2012 at 3:41 PM, Donald J.  wrote:
> 
> > I am testing an SSHD server on a new z/OS 1.12 system.
> > The connections are failing with following messages on the client side:
> > debug1: Remote protocol version 2.0, remote software version
> > OpenSSH_5.0.
> > debug1: match: OpenSSH_5.0 pat OpenSSH*.
> > debug1: Enabling compatibility mode for protocol 2.0.
> > debug1: Local version string SSH-2.0-OpenSSH_5.0.
> > debug2: fd 4 setting O_NONBLOCK.
> > debug3: RNG is ready, skipping seeding.
> > debug1: SSH2_MSG_KEXINIT sent.
> > debug3: __catgets: NLS setup complete (1), using message catalog
> > openssh.cat.
> > FOTS1930 Read from socket failed: EDC8121I Connection reset..
> >
> > The SSHD server error messages are:
> > debug1: Client protocol version 2.0; client software version
> > PuTTY_Release_0.62
> > debug1: no match: PuTTY_Release_0.62
> > debug1: Enabling compatibility mode for protocol 2.0
> > debug1: Local version string SSH-2.0-OpenSSH_5.0
> > debug2: fd 3 setting O_NONBLOCK
> > debug2: Network child is on pid 50331751
> > debug3: Current IBM Release level: 22
> > debug3: MLS: seclabel of AS:  uid:0  pid:67108965
> > debug3: MLS: peer socket: rc:0 t:0 seclabel: terminal:C0A8143D
> > poe_profile:
> > Port of Entry information retained for uid:0  pid:67108965.
> > debug3: MLS: seclabel of AS:  uid:0  pid:67108965
> > debug3: MLS: peer socket: rc:0 t:0 seclabel: terminal:C0A8143D
> > poe_profile:
> > debug3: MLS: /var/empty: rc:0 t:1 seclabel: terminal: poe_profile:
> > debug3: preauth child monitor started
> > debug3: mm_request_receive entering
> > debug1: do_cleanup
> >
> > The configuration worked fine on z/OS 1.11.  The 1.12 SFTP client works
> > fine.
> > The error messages seem to indicate an MLS port of entry issue.  I have
> > tried both
> > userid/password logins and publickey connections.
> > PublickeyAuthentication and
> > UseLogin are yes.  I also tried connecting with client on same LPAR as
> > server, so
> > it is not a firewall or network issue.
> >
> >
> >
> > --
> > http://www.fastmail.fm - Access all of your messages and folders
> >   wherever you are
> >
> > --
> > 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

-- 
http://www.fastmail.fm - The way an email service should be

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

Re: IBM, id's to open pmr's, lot$a $$$$ now involved?...

[zMan]

On Thu, Oct 11, 2012 at 2:12 PM, Paul Peplinski wrote:

> We have 10 of us that can open SRs (along with SIS, AST, and SRD) but only
> one of us has Q&A. We do not have that Enterprise agreement.


Or so you think :-(
-- 
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: FW: how do you answer the "My job is too important to follow normal channels for help" statement?

[zMan]

On Thu, Oct 11, 2012 at 2:03 PM, McKown, John  wrote:

> From another, i-series related, email forum.
> -Original Message-
> From: midrange-nontech-boun...@midrange.com [mailto:
> midrange-nontech-boun...@midrange.com] On Behalf Of Gqcy
> Sent: Thursday, October 11, 2012 12:56 PM
> To: midrange-nont...@midrange.com
> Subject: how do you answer the "My job is too important to follow normal
> channels for help" statement?
>
> We all have had this I'm sure...
> we get a phone call, personal visit, or pass in the hall,
> the person who needs help.  Your company has an established
> help procedure, and we are, as a basic requirement of employment
> forced to follow it.
> You kindly remind the user the policy, to put in a call for support
> in the proper manor, but before you get the first sentence leaves your
> lips you are presented with the cold hard facts of:
> "My job (or "this problem") is much too important to wait"
> "Management has no idea what my needs are"
> "My problem doesn't fit into any know category known to man"
>
> I post this question, because apparently the correct response is NOT:
> "The management of this company, up through the top executives have said
> that within a 1 hour response to the highest priority problem is the
> standard for all users/departments."
>

I don't understand. "See my manager please; if (s)he wants me to work on
it, in violation of company standards, that's fine. Meanwhile, I'm afraid I
can't help you."

Seems pretty simple...what am I missing?
-- 
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: Delete Catalogs from VVCR

[Mike Schwab]

I have this jcl to run before taking a volume offline.

//jobname JOB acct,programmer,CLASS=c  etc
//SDELVVDS EXEC PGM=IDCAMS
//Vvolser  DD   UNIT=DISK,VOL=SER=volser,DISP=SHR
//SYSPRINT DD   SYSOUT=*
//SYSINDD   *
   DELETE SYS1.VVDS.Vvolser CAT(ICFCAT.usercat1) FILE(Vvolser) NSCR
   DELETE SYS1.VVDS.Vvolser CAT(SYS1.MVSCTLG$) FILE(Vvolser) NSCR
   IF MAXCC EQ 8 THEN SET MAXCC = 0
   DELETE SYS1.VVDS.Vvolser CAT(ICFCAT.usercat9) FILE(Vvolser)
Make sure the last DELETE without the NSCR (after the IF) exists and
you should be set.

(This might be different than what you need to do.)

On Thu, Oct 11, 2012 at 1:46 PM, Martin, Larry D  wrote:
> I have old (no longer exist) catalog names in the VVCR record of many VVDS's.
>
> It says in "z/OS V1R13.0 DFSMS AMS for Catalogs":
>
> Only catalogs that reside on the
> converted volume need to have their names in the VVCR. You can
> remove unneeded catalog names from the VVCR by using DELETE
> VVDS NOSCRATCH with the CATALOG parameter referencing the
> catalog to be deleted from the VVCR.
>
> I have tried a few variations with no success.  Does anyone know how to code 
> the IDCAMS statements to accomplish this task?
>
> (In accordance with another topic on the list - we can't ask questions at 
> all).
>
> Thanks,.Larry
>
>
>
>
> This E-mail and any of its attachments may contain Prince George’s
> County Government or Prince George's County 7th Judicial Circuit
> Court proprietary information or Protected Health Information,
> which is privileged and confidential.  This E-mail is intended
> solely for the use of the individual or entity to which it is
> addressed.  If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited by federal law
> and may expose you to civil and/or criminal penalties. If you have
> received this E-mail in error, please notify the sender immediately
> and permanently delete the original and any copy of this E-mail and
> any printout.
>
> --
> 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: Delete Catalogs from VVCR

[Gibney, Dave]

And the error msg is? Do you have the required authority?
This is where T-Rexx (Dinosoft) or CR+ come in  handy.

I have also found that there is no benefit in being anal about these actually 
harmless entries.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Martin, Larry D
> Sent: Thursday, October 11, 2012 11:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Delete Catalogs from VVCR
> 
> I have old (no longer exist) catalog names in the VVCR record of many
> VVDS's.
> 
> It says in "z/OS V1R13.0 DFSMS AMS for Catalogs":
> 
> Only catalogs that reside on the
> converted volume need to have their names in the VVCR. You can
> remove unneeded catalog names from the VVCR by using DELETE
> VVDS NOSCRATCH with the CATALOG parameter referencing the
> catalog to be deleted from the VVCR.
> 
> I have tried a few variations with no success.  Does anyone know how to code
> the IDCAMS statements to accomplish this task?
> 
> (In accordance with another topic on the list - we can't ask questions at 
> all).
> 
> Thanks,.Larry
> 
> 
> 
> 
> This E-mail and any of its attachments may contain Prince George’s
> County Government or Prince George's County 7th Judicial Circuit
> Court proprietary information or Protected Health Information,
> which is privileged and confidential.  This E-mail is intended
> solely for the use of the individual or entity to which it is
> addressed.  If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited by federal law
> and may expose you to civil and/or criminal penalties. If you have
> received this E-mail in error, please notify the sender immediately
> and permanently delete the original and any copy of this E-mail and
> any printout.
> 
> --
> 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

Delete Catalogs from VVCR

[Martin, Larry D]

I have old (no longer exist) catalog names in the VVCR record of many VVDS's.

It says in "z/OS V1R13.0 DFSMS AMS for Catalogs":

Only catalogs that reside on the
converted volume need to have their names in the VVCR. You can
remove unneeded catalog names from the VVCR by using DELETE
VVDS NOSCRATCH with the CATALOG parameter referencing the
catalog to be deleted from the VVCR.

I have tried a few variations with no success.  Does anyone know how to code 
the IDCAMS statements to accomplish this task?

(In accordance with another topic on the list - we can't ask questions at all).

Thanks,.Larry




This E-mail and any of its attachments may contain Prince George’s
County Government or Prince George's County 7th Judicial Circuit
Court proprietary information or Protected Health Information,
which is privileged and confidential.  This E-mail is intended
solely for the use of the individual or entity to which it is
addressed.  If you are not the intended recipient of this E-mail,
you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and
attachments to this E-mail is strictly prohibited by federal law
and may expose you to civil and/or criminal penalties. If you have
received this E-mail in error, please notify the sender immediately
and permanently delete the original and any copy of this E-mail and
any printout.

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

Re: IBM, id's to open pmr's, lot$a $$$$ now involved?...

[Paul Peplinski]

We have 10 of us that can open SRs (along with SIS, AST, and SRD) but only one 
of us has Q&A. We do not have that Enterprise agreement.

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

FW: how do you answer the "My job is too important to follow normal channels for help" statement?

[McKown, John]

>From another, i-series related, email forum.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


-Original Message-
From: midrange-nontech-boun...@midrange.com 
[mailto:midrange-nontech-boun...@midrange.com] On Behalf Of Gqcy
Sent: Thursday, October 11, 2012 12:56 PM
To: midrange-nont...@midrange.com
Subject: how do you answer the "My job is too important to follow normal 
channels for help" statement?

We all have had this I'm sure...
we get a phone call, personal visit, or pass in the hall,
the person who needs help.  Your company has an established
help procedure, and we are, as a basic requirement of employment
forced to follow it.
You kindly remind the user the policy, to put in a call for support
in the proper manor, but before you get the first sentence leaves your
lips you are presented with the cold hard facts of:
"My job (or "this problem") is much too important to wait"
"Management has no idea what my needs are"
"My problem doesn't fit into any know category known to man"

I post this question, because apparently the correct response is NOT:
"The management of this company, up through the top executives have said
that within a 1 hour response to the highest priority problem is the 
standard for all users/departments."



-- 
This is the Non-Technical Discussion about the AS400 / iSeries 
(Midrange-NonTech) mailing list
To post a message email: midrange-nont...@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-nontech
or email: midrange-nontech-requ...@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-nontech.

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

Re: IBM, id's to open pmr's, lot$a $$$$ now involved?...

[Brian France]

Well I continue to push. I'm asking for documentation as to when this 
change went into effect. Clarification on the dollar$ cause, WOW!!  
Still am being told we never should've been able to do what we've been 
doing. I state back there's a hell of a lot of others in the world doing 
this and you mean to tell me you've left us all go for 10-12 years. 
Absurd...  I want the documentation on the new policy...  To change ones 
user id WITHOUT giving them notification is beyond ludicrous. To change 
every ones at a site and not notify them is totally unacceptable. If 
this does pan out to be no wonder people are leaving. NOT one other 
vendor does this. IBM, you are $ad...



 To answer gil's question.

SoftwareXcel basic - is a per user id job that aparently doesn't have 
some features of the the. We picked up basic say 5 or so years back just 
to ask How To questions.


SoftwareXcel enterprise - to my understanding as many id's as you'd 
like. When I got to 7 this is were I was told I should be. Based on the 
quote, it was indeed cheaper.


On 10/11/2012 11:59 AM, Joel C. Ewing wrote:

On 10/11/2012 08:37 AM, Paul Gilmartin wrote:

On Thu, 11 Oct 2012 06:07:35 -0700, Phil Smith wrote:
So it sounds like they've lost the distinction between HOWTO and bug 
reports. That would be a big step backward, and indeed irritating. I 
do understand the *theory* behind this: if every Tom, Dick, and Jane 
at every IBM customer can open PMRs, they'll be swamped with Stupid 
User questions, and not get any real bugs fixed. But that doesn't 
justify forcing it all through one ID: if they're going to do that, 
they're basically encouraging shared IDs, which is a bad idea (and 
likely prohibited by their TOS, but that's another issue). Limiting 
it to some reasonable number - maybe ten - IDs per installation 
might make sense, but we all know that in large shops, the DB2 guys 
and the sysprogs may not even know each other's names, so one is 
ludicrous.



Is this per user x per product?

per user x per product x per licensed system?

-- gil


At least in the past it was the case that chargeable on-line service 
support costs were purely based on number of authorized users at the 
installation, without regard for number of product licenses or 
systems.   The product licenses only entered into consideration in 
that one instance of the product under maintenance license was 
sufficient to allow the installation to open PMRs against the product.


If you didn't have the required on-line access to report a PMR on a 
licensed product, the alternative was to telephone the Support 
Center.  I would think reporting problems by phone would have to be 
more labor intensive and more costly for IBM, not just an irritant for 
the customer having to wait around for phone queue call-backs and 
trying to explain verbally something best illustrated by cut and paste 
or digital documentation. It makes absolutely no sense to me that IBM 
would think it a good idea to discourage PMR reporting by erecting 
financial barriers to the most efficient reporting methods, as the end 
result is that their knowledge of problems and problem resolution will 
be delayed, causing their product quality to suffer if installations 
are discouraged from reporting problems in a timely fashion.  When an 
installation reports a problem, the resolution of that problem doesn't 
just benefit that installation, but potentially all other 
installations using that product.  The reporting installation is 
actually performing a "service" for IBM, so the ease of reporting and 
the costs that IBM expects the installation to incur for that process 
should reflect that fact!


In the spirit of SHARE, we would even occasionally report a problem 
for which we already had found a circumvention, especially if the 
resolution had taken a significant effort on our part and finding an 
APAR resolution would be an obvious benefit for others (and if we 
didn't want to fight the same problem in the next product release).




--

--

Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu 

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

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

Re: Did ShopzSeries change the way they deliver RSU maintenance ?

[Bonno, Tuco]

I downloaded rsu 1207, 1208, 1209 earlier today; took a couple of hours, but it 
completed successfully for me 


/s/ tuco bonno; 
Graduate, College of Conflict Management;
University of SouthEast Asia;
"I partied on the Ho Chi Minh Trail - tiến lên !! "






-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Thursday, 11 October, 2012 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Did ShopzSeries change the way they deliver RSU maintenance ?

Odd that I had no issues with downloading RSU on Monday, but on Tuesday and now 
today every time I try to download an RSU my FTP stalls.

On Wed, Oct 10, 2012 at 9:36 AM, Alvaro Guirao Lopez  wrote:

> I have been suffering similar problems lastly.
>
> Downloads take a long time to be available for download, I have 
> received firstly the e@mail with the notification that the download is 
> available, but when I go to ShopZSeries appears "Shipped/Download 
> Ready", I must wait to the next morning to download it!
>
> 2012/10/10 Mark Pace 
>
> > I ordered and downloaded RSU1209 yesterday.  No change on how I 
> > ordered
> it,
> > or how I downloaded it.  The contents have changed somewhat, but the
> order
> > and downloaded worked the same as always.
> >
> > On Mon, Oct 8, 2012 at 3:29 PM, Patrick Lyon 
> > 
> > wrote:
> >
> > > On Mon, 8 Oct 2012 19:17:13 +, Daniel Allen 
> > > 
> > wrote:
> > >
> > > >I ordered PUT1209 this morning. The order says Shipped/Download Ready.
> > > However, I cannot click on the Status and get the information I 
> > > need to download.
> > > >
> > > >Was the information email to the person responsible ?
> > > >
> > > >-
> > > >- For IBM-MAIN subscribe / signoff / archive access 
> > > >instructions, send email to lists...@listserv.ua.edu with the 
> > > >message: INFO
> IBM-MAIN
> > >
> > > Same here on a CBPDO I ordered Friday.  Got the download email at
> 11:30,
> > 3
> > > hours later it shows just like yours.
> > >
> > > --
> > >  For IBM-MAIN subscribe / signoff / archive access 
> > > instructions, send email to lists...@listserv.ua.edu with the 
> > > message: INFO IBM-MAIN
> > >
> >
> >
> >
> > --
> > The postings on this site are my own and don’t necessarily represent 
> > Mainline’s positions or opinions
> >
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
>
>
>
> --
> Un saludo.
> Álvaro Guirao
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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: Slip trap for cross memory mode

[Chuck Arney]

I responded to Ron off list about how we will support this in the future.

Chuck Arney
Arney Computer Systems
http://zosdebug.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron MacRae
Sent: Thursday, October 11, 2012 4:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Slip trap for cross memory mode

Chuck,
  I don't think your product, or any other real time debugger, wouldn't 
help in our situation.  

1) The problem we are trying to debug is happening on our customer's production 
system. The system recovers as best it can and continues to run but we don't 
take a dump. They cannot reproduce it in test, neither can we.

2) The problem is volume and timing related and only happens in a heavily 
stressed system that is running with multiple full blown zIIPs and a couple of 
very slugged CPs. The minimal housekeeping on the CP doesn't seem to be keeping 
up with the work being done on the zIIPs.

Thanks to Jim Mulder I've now got a slip I can try.  I just hope the slip being 
active doesn't change the timing such that the problem doesn't happen.

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

Re: IBM, id's to open pmr's, lot$a $$$$ now involved?...

[Charles Mills]

> In the spirit of SHARE, we would even occasionally 
> report a problem for which we already had found a circumvention

I have had a long-open SR, in which I have invested a lot of hours -- SOLELY 
because the group here told me I was being a bad citizen if I did not report 
the bug, even though I had found a perfectly acceptable way around it.

And yes, not I have run into the SoftwareXcel restriction -- I could not even 
UPDATE my EXISTING SR after IBM asked me for more information. VERY annoying.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Thursday, October 11, 2012 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM, id's to open pmr's, lot$a  now involved?...

On 10/11/2012 08:37 AM, Paul Gilmartin wrote:
> On Thu, 11 Oct 2012 06:07:35 -0700, Phil Smith wrote:
>> So it sounds like they've lost the distinction between HOWTO and bug 
>> reports. That would be a big step backward, and indeed irritating. I do 
>> understand the *theory* behind this: if every Tom, Dick, and Jane at every 
>> IBM customer can open PMRs, they'll be swamped with Stupid User questions, 
>> and not get any real bugs fixed. But that doesn't justify forcing it all 
>> through one ID: if they're going to do that, they're basically encouraging 
>> shared IDs, which is a bad idea (and likely prohibited by their TOS, but 
>> that's another issue). Limiting it to some reasonable number - maybe ten - 
>> IDs per installation might make sense, but we all know that in large shops, 
>> the DB2 guys and the sysprogs may not even know each other's names, so one 
>> is ludicrous.
>>
> Is this per user x per product?
>
> per user x per product x per licensed system?
>
> -- gil
>
>
At least in the past it was the case that chargeable on-line service 
support costs were purely based on number of authorized users at the 
installation, without regard for number of product licenses or systems. 
   The product licenses only entered into consideration in that one 
instance of the product under maintenance license was sufficient to 
allow the installation to open PMRs against the product.

If you didn't have the required on-line access to report a PMR on a 
licensed product, the alternative was to telephone the Support Center.  
I would think reporting problems by phone would have to be more labor 
intensive and more costly for IBM, not just an irritant for the customer 
having to wait around for phone queue call-backs and trying to explain 
verbally something best illustrated by cut and paste or digital 
documentation. It makes absolutely no sense to me that IBM would think 
it a good idea to discourage PMR reporting by erecting financial 
barriers to the most efficient reporting methods, as the end result is 
that their knowledge of problems and problem resolution will be delayed, 
causing their product quality to suffer if installations are discouraged 
from reporting problems in a timely fashion.  When an installation 
reports a problem, the resolution of that problem doesn't just benefit 
that installation, but potentially all other installations using that 
product.  The reporting installation is actually performing a "service" 
for IBM, so the ease of reporting and the costs that IBM expects the 
installation to incur for that process should reflect that fact!

In the spirit of SHARE, we would even occasionally report a problem for 
which we already had found a circumvention, especially if the resolution 
had taken a significant effort on our part and finding an APAR 
resolution would be an obvious benefit for others (and if we didn't want 
to fight the same problem in the next product release).

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

Re: DFHSM Recalls and Tape

[retired mainframer]

Why not run a small test with 10-15 datasets on 2-3 tape volumes?  You may
discover that your shop has some feature that prevents HSM from managing the
tapes intelligently.

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of Lizette Koehler
:>: Sent: Thursday, October 11, 2012 6:15 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Re: DFHSM Recalls and Tape
:>:
:>: Everyone thanks so much for confirming what I was told.
:>:
:>: Where my problem arises is when a user wants to recall 5000 or more
:>: datasets.  I was concerned that the recall process would serialize it
:>: rather
:>: than finding all the files on a given migration tape and work with it
:>: until
:>: it needed a new tape.

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

Destination z article: Competent complaining creates constructive catastrophe conclusion climate

[Gabe Goldberg]

Competent complaining creates constructive catastrophe conclusion climate

http://destinationz.org/Mainframe-Solution/Systems-Administration/Competent-Complaining-Creates-Constructive-Catastr.aspx

Thanks for input; next query to come shortly...

--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0

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

Re: IBM, id's to open pmr's, lot$a $$$$ now involved?...

[Joel C. Ewing]

On 10/11/2012 08:37 AM, Paul Gilmartin wrote:

On Thu, 11 Oct 2012 06:07:35 -0700, Phil Smith wrote:

So it sounds like they've lost the distinction between HOWTO and bug reports. 
That would be a big step backward, and indeed irritating. I do understand the 
*theory* behind this: if every Tom, Dick, and Jane at every IBM customer can 
open PMRs, they'll be swamped with Stupid User questions, and not get any real 
bugs fixed. But that doesn't justify forcing it all through one ID: if they're 
going to do that, they're basically encouraging shared IDs, which is a bad idea 
(and likely prohibited by their TOS, but that's another issue). Limiting it to 
some reasonable number - maybe ten - IDs per installation might make sense, but 
we all know that in large shops, the DB2 guys and the sysprogs may not even 
know each other's names, so one is ludicrous.


Is this per user x per product?

per user x per product x per licensed system?

-- gil


At least in the past it was the case that chargeable on-line service 
support costs were purely based on number of authorized users at the 
installation, without regard for number of product licenses or systems. 
  The product licenses only entered into consideration in that one 
instance of the product under maintenance license was sufficient to 
allow the installation to open PMRs against the product.


If you didn't have the required on-line access to report a PMR on a 
licensed product, the alternative was to telephone the Support Center.  
I would think reporting problems by phone would have to be more labor 
intensive and more costly for IBM, not just an irritant for the customer 
having to wait around for phone queue call-backs and trying to explain 
verbally something best illustrated by cut and paste or digital 
documentation. It makes absolutely no sense to me that IBM would think 
it a good idea to discourage PMR reporting by erecting financial 
barriers to the most efficient reporting methods, as the end result is 
that their knowledge of problems and problem resolution will be delayed, 
causing their product quality to suffer if installations are discouraged 
from reporting problems in a timely fashion.  When an installation 
reports a problem, the resolution of that problem doesn't just benefit 
that installation, but potentially all other installations using that 
product.  The reporting installation is actually performing a "service" 
for IBM, so the ease of reporting and the costs that IBM expects the 
installation to incur for that process should reflect that fact!


In the spirit of SHARE, we would even occasionally report a problem for 
which we already had found a circumvention, especially if the resolution 
had taken a significant effort on our part and finding an APAR 
resolution would be an obvious benefit for others (and if we didn't want 
to fight the same problem in the next product release).


--
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: DFHSM Recalls and Tape

[Elardus Engelbrecht]

On Thu, 11 Oct 2012 10:19:59 -0400, O'Brien, David W. (NIH/CIT) [C] 
 wrote:

>I think you missed the distinction between submitting recalls and a process 
>causing recalls. At this shop it was not unusual for a user to submit an 
>Iefbr14 job to delete datasets thereby causing the recall of any dataset that 
>had been migrated. Since the recall is serial, it would result in one tape 
>mount per recall.

Agreed that I  missed that distinction. I agree there is ONE mount per recall. 
But I will stay with what I said about the problem of handling a lot of recalls 
requests and subsequent mounts. 

I think the IEFBR14 recall problem has been fixed in the last 5 years or so. 
AFAIK it is a setting in ALLOCxx member.

Thanks Dave!

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: Did ShopzSeries change the way they deliver RSU maintenance ?

[Mark Pace]

Odd that I had no issues with downloading RSU on Monday, but on Tuesday and
now today every time I try to download an RSU my FTP stalls.

On Wed, Oct 10, 2012 at 9:36 AM, Alvaro Guirao Lopez  wrote:

> I have been suffering similar problems lastly.
>
> Downloads take a long time to be available for download, I have received
> firstly the e@mail with the notification that the download is available,
> but when I go to ShopZSeries appears "Shipped/Download Ready", I must wait
> to the next morning to download it!
>
> 2012/10/10 Mark Pace 
>
> > I ordered and downloaded RSU1209 yesterday.  No change on how I ordered
> it,
> > or how I downloaded it.  The contents have changed somewhat, but the
> order
> > and downloaded worked the same as always.
> >
> > On Mon, Oct 8, 2012 at 3:29 PM, Patrick Lyon 
> > wrote:
> >
> > > On Mon, 8 Oct 2012 19:17:13 +, Daniel Allen 
> > wrote:
> > >
> > > >I ordered PUT1209 this morning. The order says Shipped/Download Ready.
> > > However, I cannot click on the Status and get the information I need to
> > > download.
> > > >
> > > >Was the information email to the person responsible ?
> > > >
> > > >--
> > > >For IBM-MAIN subscribe / signoff / archive access instructions,
> > > >send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > >
> > > Same here on a CBPDO I ordered Friday.  Got the download email at
> 11:30,
> > 3
> > > hours later it shows just like yours.
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> >
> >
> > --
> > The postings on this site are my own and don’t necessarily represent
> > Mainline’s positions or opinions
> >
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> Un saludo.
> Álvaro Guirao
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: DFHSM Recalls and Tape

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

Thanks Allan, the norecall option is specified in our ALLOxx member. I did use 
the past tense in my posting. There are however other processes that do the 
same thing here with the same redundant HSM tape mounts. I was just using 
Iefbr14 as an example that all would be familiar with.

Dave O'Brien

-Original Message-
From: Staller, Allan [mailto:allan.stal...@kbmg.com] 
Sent: Thursday, October 11, 2012 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Recalls and Tape

See ' SYSTEM IEFBR14_DELMIGDS(NORECALL)' in SYS1.PARMLIB(ALLOCxx). New with 
z/OS 1.11 (?)


At this shop it was not unusual for a user to submit an Iefbr14 job to delete 
datasets thereby causing the recall of any dataset that had been migrated. 
Since the recall is serial, it would result in one tape mount per recall.



--
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: DFHSM Recalls and Tape

[Staller, Allan]

See ' SYSTEM IEFBR14_DELMIGDS(NORECALL)' in SYS1.PARMLIB(ALLOCxx). New with 
z/OS 1.11 (?)


At this shop it was not unusual for a user to submit an Iefbr14 job to delete 
datasets thereby causing the recall of any dataset that had been migrated. 
Since the recall is serial, it would result in one tape mount per recall.



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

Re: DFHSM Recalls and Tape

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

Elardus,

I think you missed the distinction between submitting recalls and a process 
causing recalls. At this shop it was not unusual for a user to submit an 
Iefbr14 job to delete datasets thereby causing the recall of any dataset that 
had been migrated. Since the recall is serial, it would result in one tape 
mount per recall.

Dave O'Brien  

-Original Message-
From: Elardus Engelbrecht [mailto:elardus.engelbre...@sita.co.za] 
Sent: Thursday, October 11, 2012 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Recalls and Tape

O'Brien, David W. wrote:

>One caveat, if I may. Is your user submitting 5000 Hrecalls or are they 
>submitting a process which will result in 5000 recalls? The latter could 
>result in 5000 tape mounts.

No. Look up on TAPEMAXRECALLTASKS and MAXRECALLTASKS. So in your example with 
TAPEMAXRECALLTASKS(10) you will use 10 tape mounts at a stage, not 5000 mounts. 

But yes, if all those datasets are residing on 5000 tapes, this is going to be 
a looong wait and very tired [1] ops. ;-)

Lizette: You can have your mounts split up on several LPARS to spread out 
workload. Say 10 mounts on LPAR1, 20 mounts on LPAR2, etc. Check out the CRQ 
function of HSM.

HTH!

Groete / Greetings
Elardus Engelbrecht

[1] - Since we got a robot, incorrect mounts disappeared... unless you get a 
x13 or x14 abend. Then these ops eject it, INIT it and re-mount it with 
disastrous results!

--
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: DFHSM Recalls and Tape

[Elardus Engelbrecht]

O'Brien, David W. wrote:

>One caveat, if I may. Is your user submitting 5000 Hrecalls or are they 
>submitting a process which will result in 5000 recalls? The latter could 
>result in 5000 tape mounts.

No. Look up on TAPEMAXRECALLTASKS and MAXRECALLTASKS. So in your example with 
TAPEMAXRECALLTASKS(10) you will use 10 tape mounts at a stage, not 5000 mounts. 

But yes, if all those datasets are residing on 5000 tapes, this is going to be 
a looong wait and very tired [1] ops. ;-)

Lizette: You can have your mounts split up on several LPARS to spread out 
workload. Say 10 mounts on LPAR1, 20 mounts on LPAR2, etc. Check out the CRQ 
function of HSM.

HTH!

Groete / Greetings
Elardus Engelbrecht

[1] - Since we got a robot, incorrect mounts disappeared... unless you get a 
x13 or x14 abend. Then these ops eject it, INIT it and re-mount it with 
disastrous results!

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

Re: IBM, id's to open pmr's, lot$a $$$$ now involved?...

[Paul Gilmartin]

On Thu, 11 Oct 2012 06:07:35 -0700, Phil Smith wrote:
>
>So it sounds like they've lost the distinction between HOWTO and bug reports. 
>That would be a big step backward, and indeed irritating. I do understand the 
>*theory* behind this: if every Tom, Dick, and Jane at every IBM customer can 
>open PMRs, they'll be swamped with Stupid User questions, and not get any real 
>bugs fixed. But that doesn't justify forcing it all through one ID: if they're 
>going to do that, they're basically encouraging shared IDs, which is a bad 
>idea (and likely prohibited by their TOS, but that's another issue). Limiting 
>it to some reasonable number - maybe ten - IDs per installation might make 
>sense, but we all know that in large shops, the DB2 guys and the sysprogs may 
>not even know each other's names, so one is ludicrous.
> 
Is this per user x per product?

per user x per product x per licensed system?

-- gil

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

Re: DFHSM Recalls and Tape

[Lizette Koehler]

They are using a REXX that generates 

HRECALL (file1 file2 file3 file4 etc...) NOWAIT

Or some will submit a TSO Batch job with individual HRECALL file1 NOWAIT
commands.


I am not happy with this process and am I working to create a better REXX
for them to use for this.  But for now, we have requested that if they have
over 1000 recalls to be done, to let my group work on them.

The rewrite is that the command to HSM to alter priority for that userid
will also be done at the end of the HRECALL requests.  That way I can at
least place them at the bottom of the priority and let other HSM RECALLS
happen as they come into the queue.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of O'Brien, David W. (NIH/CIT) [C]
> 
> Lizette,
> 
> One caveat, if I may. Is your user submitting 5000 Hrecalls or are they
submitting a
> process which will result in 5000 recalls? The latter could result in 5000
tape mounts.
> 
> Dave O'Brien
> 
> -Original Message-
> From: Lizette Koehler [mailto:stars...@mindspring.com]
> Sent: Thursday, October 11, 2012 9:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Recalls and Tape
> 
> Everyone thanks so much for confirming what I was told.
> 
> Where my problem arises is when a user wants to recall 5000 or more
datasets.  I was
> concerned that the recall process would serialize it rather than finding
all the files on a
> given migration tape and work with it until it needed a new tape.
> 
> Very helpful
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On
> Behalf
> > Of O'Brien, David W. (NIH/CIT) [C]
> >
> > Hervey,
> >
> > That is not true, at least not at this shop. HSM routinely queues
> > recalls
> according to
> > tape volume in order to minimize tape mounts with or without CRQ.
> >
> > Dave O'Brien
> >
> > -Original Message-
> > From: Hervey Martinez [mailto:hervey.marti...@custserv.com]
> > Sent: Thursday, October 11, 2012 7:55 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFHSM Recalls and Tape
> >
> > If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead"
> and recall
> > all files that are on the same tape. Also, with CRQ, you can limit
> > which
> LPARS will
> > perform recalls and limit them in that manner and all recalls will be
> routed to that
> > LPAR. Otherwise, the recalls happen one at a time in a FIFO manner.
> >
> > Regards,
> >
> > Hervey
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On
> Behalf
> > Of Robert A. Rosenberg
> > Sent: Thursday, October 11, 2012 3:58 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFHSM Recalls and Tape
> >
> > At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM
> > Recalls
> and
> > Tape:
> >
> > >When it HSM finishes a recall, it checks the que in order for any
> > >recall on the same tape.  When it reaches the end of the que, it
> > >unmounts the tape, and starts recalling the first waiting dataset on
> > >the que.  Haven't done as massive a quantity as 10,000 though.
> > >
> > >No sorting of any kind, just checking the que DSN against the list on
> > >the mounted tape.
> >
> > So you are saying that as it reads the tape (after it has recalled a
> > file
> from the tape) it
> > sees the next file on the tape and checks if it is on the queue. It
> > then
> either recalls the
> > file (if it is on the
> > queue) or reads the tape to the next file and does the queue check
again.
> >
> >  From your "no sort" comment, I assume that it does not order the
> > queue
> based on
> > restore tape volume but just runs the full queue until it finds the
> dataset name or
> > reaches the end of the queue. If the latter it seems inefficient since
> > if
> the queue was
> > ordered by volume serial number it could stop the scan once it reached
> > an
> entry on a
> > different tape.
> 

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

Re: DFHSM Recalls and Tape

[Lizette Koehler]

Hervey,

Yes I do have CRQ in use.  I am also working to implementing MASH (Multiple
Address Space HSM) and RLS to try and provide some performance and relief to
DFHSM

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Hervey Martinez
> Sent: Thursday, October 11, 2012 6:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Recalls and Tape
> 
> Dave,
> 
> Yes I've heard that but have never seen it done without CRQ.
> 
> Regards,
> 
> Hervey
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of O'Brien, David W. (NIH/CIT) [C]
> Sent: Thursday, October 11, 2012 8:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Recalls and Tape
> 
> Hervey,
> 
> That is not true, at least not at this shop. HSM routinely queues recalls
according to
> tape volume in order to minimize tape mounts with or without CRQ.
> 
> Dave O'Brien
> 
> -Original Message-
> From: Hervey Martinez [mailto:hervey.marti...@custserv.com]
> Sent: Thursday, October 11, 2012 7:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Recalls and Tape
> 
> If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead"
and recall
> all files that are on the same tape. Also, with CRQ, you can limit which
LPARS will
> perform recalls and limit them in that manner and all recalls will be
routed to that
> LPAR. Otherwise, the recalls happen one at a time in a FIFO manner.
> 
> Regards,
> 
> Hervey
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Robert A. Rosenberg
> Sent: Thursday, October 11, 2012 3:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Recalls and Tape
> 
> At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls
and
> Tape:
> 
> >When it HSM finishes a recall, it checks the que in order for any
> >recall on the same tape.  When it reaches the end of the que, it
> >unmounts the tape, and starts recalling the first waiting dataset on
> >the que.  Haven't done as massive a quantity as 10,000 though.
> >
> >No sorting of any kind, just checking the que DSN against the list on
> >the mounted tape.
> 
> So you are saying that as it reads the tape (after it has recalled a file
from the tape) it
> sees the next file on the tape and checks if it is on the queue. It then
either recalls the
> file (if it is on the
> queue) or reads the tape to the next file and does the queue check again.
> 
>  From your "no sort" comment, I assume that it does not order the queue
based on
> restore tape volume but just runs the full queue until it finds the
dataset name or
> reaches the end of the queue. If the latter it seems inefficient since if
the queue was
> ordered by volume serial number it could stop the scan once it reached an
entry on a
> different tape.
> 
> --
> 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: SMP/E question

[Art Gutowski]

On Wed, 10 Oct 2012 08:36:42 -0700, Skip Robinson  
wrote:

>I've said previously that a DOC record requiring action should be
>(re)classified (or accompanied by) an ACTION hold. ENH in practice seems
>to be a subset DOC: informative but not requiring immediate action.

Agreed, with the operative word being *should*... Not very often these days, 
one slips through, the offender is rightly castigated by an astute sysprog, and 
others are hopefully spared the (hopefully innocuous) oversight.  I tried to at 
least skim the DOC holds just in case there was anything obviously 
mis-classified.

Regards,
Art Gutowski
Compuware

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

Re: DFHSM Recalls and Tape

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

Lizette,

One caveat, if I may. Is your user submitting 5000 Hrecalls or are they 
submitting a process which will result in 5000 recalls? The latter could result 
in 5000 tape mounts.

Dave O'Brien

-Original Message-
From: Lizette Koehler [mailto:stars...@mindspring.com] 
Sent: Thursday, October 11, 2012 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Recalls and Tape

Everyone thanks so much for confirming what I was told.

Where my problem arises is when a user wants to recall 5000 or more datasets.  
I was concerned that the recall process would serialize it rather than finding 
all the files on a given migration tape and work with it until it needed a new 
tape.

Very helpful

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On
Behalf
> Of O'Brien, David W. (NIH/CIT) [C]
> 
> Hervey,
> 
> That is not true, at least not at this shop. HSM routinely queues 
> recalls
according to
> tape volume in order to minimize tape mounts with or without CRQ.
> 
> Dave O'Brien
> 
> -Original Message-
> From: Hervey Martinez [mailto:hervey.marti...@custserv.com]
> Sent: Thursday, October 11, 2012 7:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Recalls and Tape
> 
> If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead"
and recall
> all files that are on the same tape. Also, with CRQ, you can limit 
> which
LPARS will
> perform recalls and limit them in that manner and all recalls will be
routed to that
> LPAR. Otherwise, the recalls happen one at a time in a FIFO manner.
> 
> Regards,
> 
> Hervey
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On
Behalf
> Of Robert A. Rosenberg
> Sent: Thursday, October 11, 2012 3:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Recalls and Tape
> 
> At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM 
> Recalls
and
> Tape:
> 
> >When it HSM finishes a recall, it checks the que in order for any 
> >recall on the same tape.  When it reaches the end of the que, it 
> >unmounts the tape, and starts recalling the first waiting dataset on 
> >the que.  Haven't done as massive a quantity as 10,000 though.
> >
> >No sorting of any kind, just checking the que DSN against the list on 
> >the mounted tape.
> 
> So you are saying that as it reads the tape (after it has recalled a 
> file
from the tape) it
> sees the next file on the tape and checks if it is on the queue. It 
> then
either recalls the
> file (if it is on the
> queue) or reads the tape to the next file and does the queue check again.
> 
>  From your "no sort" comment, I assume that it does not order the 
> queue
based on
> restore tape volume but just runs the full queue until it finds the
dataset name or
> reaches the end of the queue. If the latter it seems inefficient since 
> if
the queue was
> ordered by volume serial number it could stop the scan once it reached 
> an
entry on a
> different tape.

--
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: OpenPGP doesn't use crypto hardware? was Re: OpenPGP Encryption

[Steve Finch]

I then send PGP RSA encrypted data offsite.  Am I not offloading processing to 
crypto hardware (CEX2) during encryption?
--
PGP encryption does not use the hardware (CPACF/ CEX2). The data is encrypted 
with PGP

RSA encryption does use CEX2 crypto hardware in Accelerator mode (CEX2A) . The 
PGP encryption keys are encrypted with RSA

Steve Finch

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Mooney
Sent: Wednesday, October 10, 2012 6:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: OpenPGP doesn't use crypto hardware? was Re: OpenPGP Encryption

Re: "PGP is good encryption but it is not in use very much on IBM mainframes 
because the encryption can not be offloaded to crypto hardware ..."

I'm confused since the OpenPGP doc mentions hardware encryption in several 
places.

I recently had a project to get OpenPGP working on z/os 1.13.  I am using a 
public/private key pair generated with ICSF in the PKDS.  We have 2 CEX2 cards. 
 I '-prepared' my key pair with OpenPGP. During encryption I specify '-provider 
com.ibm.crypto.hdwrCCA.provider.IBMJCECCA.' I then send PGP RSA encrypted data 
offsite. 

Am I not offloading processing to crypto hardware (CEX2) during encryption?

-Jim

--
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: DFHSM Recalls and Tape

[Lizette Koehler]

Everyone thanks so much for confirming what I was told.

Where my problem arises is when a user wants to recall 5000 or more
datasets.  I was concerned that the recall process would serialize it rather
than finding all the files on a given migration tape and work with it until
it needed a new tape.

Very helpful

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of O'Brien, David W. (NIH/CIT) [C]
> 
> Hervey,
> 
> That is not true, at least not at this shop. HSM routinely queues recalls
according to
> tape volume in order to minimize tape mounts with or without CRQ.
> 
> Dave O'Brien
> 
> -Original Message-
> From: Hervey Martinez [mailto:hervey.marti...@custserv.com]
> Sent: Thursday, October 11, 2012 7:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Recalls and Tape
> 
> If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead"
and recall
> all files that are on the same tape. Also, with CRQ, you can limit which
LPARS will
> perform recalls and limit them in that manner and all recalls will be
routed to that
> LPAR. Otherwise, the recalls happen one at a time in a FIFO manner.
> 
> Regards,
> 
> Hervey
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Robert A. Rosenberg
> Sent: Thursday, October 11, 2012 3:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Recalls and Tape
> 
> At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls
and
> Tape:
> 
> >When it HSM finishes a recall, it checks the que in order for any
> >recall on the same tape.  When it reaches the end of the que, it
> >unmounts the tape, and starts recalling the first waiting dataset on
> >the que.  Haven't done as massive a quantity as 10,000 though.
> >
> >No sorting of any kind, just checking the que DSN against the list on
> >the mounted tape.
> 
> So you are saying that as it reads the tape (after it has recalled a file
from the tape) it
> sees the next file on the tape and checks if it is on the queue. It then
either recalls the
> file (if it is on the
> queue) or reads the tape to the next file and does the queue check again.
> 
>  From your "no sort" comment, I assume that it does not order the queue
based on
> restore tape volume but just runs the full queue until it finds the
dataset name or
> reaches the end of the queue. If the latter it seems inefficient since if
the queue was
> ordered by volume serial number it could stop the scan once it reached an
entry on a
> different tape.

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

Re: IBM, id's to open pmr's, lot$a $$$$ now involved?...

[Phil Smith]

Brian France wrote:
> I'm surmising that y'all, like us, have multiple user id's for support at 
> www.ibm.com/support. We have several people here that have opened PMR's over 
> the past many many years. A couple of weeks back I went in to open an issue 
> and found that I was no longer entitled to z/OS. What I found out was that 
> only one person in my group could open a z/OS related PMR. After some 
> questions to many IBM'ers my id was set back, no one knowing why the change 
> had occurred. In trying to get the rest of my colleagues their access back 
> I'm told that we will have to pay. That only my ID has Software Xcel and it's 
> the basic. Well, yes, we knew that. Several years ago we opted to take it as 
> the only id that could ask HOW to Support questions. Now I'm told that if all 
> my colleagues are to have id's to open PMR's, which is 7 of us, that we would 
> have to move to SoftwareXcel Enterprise and the quote is quite an eye popper. 
>  So, long story short, I'm interested in the rest of ya... Any one seen this 
> yet? Hell, even CA doesn't charge for userid's to open problem support 
> records for software we are already paying support on.

So it sounds like they've lost the distinction between HOWTO and bug reports. 
That would be a big step backward, and indeed irritating. I do understand the 
*theory* behind this: if every Tom, Dick, and Jane at every IBM customer can 
open PMRs, they'll be swamped with Stupid User questions, and not get any real 
bugs fixed. But that doesn't justify forcing it all through one ID: if they're 
going to do that, they're basically encouraging shared IDs, which is a bad idea 
(and likely prohibited by their TOS, but that's another issue). Limiting it to 
some reasonable number - maybe ten - IDs per installation might make sense, but 
we all know that in large shops, the DB2 guys and the sysprogs may not even 
know each other's names, so one is ludicrous.

The fact that nobody at your end knew about the change isn't good, either. If 
this had been a 3AM SEV1, things could have gotten nasty...

Surely one of the good IBMers on this list can find the real scoop. If this is 
really the policy, then it needs work.
--
...phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com


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

Re: DFHSM Recalls and Tape

[Hervey Martinez]

Dave,

Yes I've heard that but have never seen it done without CRQ.

Regards,

Hervey


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of O'Brien, David W. (NIH/CIT) [C]
Sent: Thursday, October 11, 2012 8:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Recalls and Tape

Hervey,

That is not true, at least not at this shop. HSM routinely queues recalls 
according to tape volume in order to minimize tape mounts with or without CRQ.

Dave O'Brien

-Original Message-
From: Hervey Martinez [mailto:hervey.marti...@custserv.com]
Sent: Thursday, October 11, 2012 7:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Recalls and Tape

If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and 
recall all files that are on the same tape. Also, with CRQ, you can limit which 
LPARS will perform recalls and limit them in that manner and all recalls will 
be routed to that LPAR. Otherwise, the recalls happen one at a time in a FIFO 
manner.

Regards,

Hervey

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert A. Rosenberg
Sent: Thursday, October 11, 2012 3:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Recalls and Tape

At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls and 
Tape:

>When it HSM finishes a recall, it checks the que in order for any 
>recall on the same tape.  When it reaches the end of the que, it 
>unmounts the tape, and starts recalling the first waiting dataset on 
>the que.  Haven't done as massive a quantity as 10,000 though.
>
>No sorting of any kind, just checking the que DSN against the list on 
>the mounted tape.

So you are saying that as it reads the tape (after it has recalled a file from 
the tape) it sees the next file on the tape and checks if it is on the queue. 
It then either recalls the file (if it is on the
queue) or reads the tape to the next file and does the queue check again.

 From your "no sort" comment, I assume that it does not order the queue based 
on restore tape volume but just runs the full queue until it finds the dataset 
name or reaches the end of the queue. If the latter it seems inefficient since 
if the queue was ordered by volume serial number it could stop the scan once it 
reached an entry on a different tape.

--
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: Question about Catalogs and VSAM

[Larry Crilley]

If you are asking about opening a VSAM file after an allocation of DISP=OLD,
then as others here have said, GRS will prevent you from allocation/OPEN on
other systems within the SYSPLEX.  However, if you are asking about an
allocation of SHR and allowing VSAM SHROPTs to protect you, then you have a
different situation.  Since each file resides in a different catalog
(different names), then the ENQ issued by VSAM will be different.  When a
VSAM file is OPENED, a series of SYSVSAM ENQs are obtained.  The series of
ENQs will differ depending upon the files SHROPTs.  Part of the SYSVSAM
RNAME is the catalog name.  Since you have different catalog names, then the
SYSVSAM ENQs on each system would differ.

 

Larry Crilley

Dino-Software Corporation

800.480.DINO

412.366.3566

 
 www.dino-software.com

 


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

Re: DFHSM Recalls and Tape

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

Hervey,

That is not true, at least not at this shop. HSM routinely queues recalls 
according to tape volume in order to minimize tape mounts with or without CRQ.

Dave O'Brien

-Original Message-
From: Hervey Martinez [mailto:hervey.marti...@custserv.com] 
Sent: Thursday, October 11, 2012 7:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Recalls and Tape

If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and 
recall all files that are on the same tape. Also, with CRQ, you can limit which 
LPARS will perform recalls and limit them in that manner and all recalls will 
be routed to that LPAR. Otherwise, the recalls happen one at a time in a FIFO 
manner.

Regards,

Hervey

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert A. Rosenberg
Sent: Thursday, October 11, 2012 3:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Recalls and Tape

At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls and 
Tape:

>When it HSM finishes a recall, it checks the que in order for any 
>recall on the same tape.  When it reaches the end of the que, it 
>unmounts the tape, and starts recalling the first waiting dataset on 
>the que.  Haven't done as massive a quantity as 10,000 though.
>
>No sorting of any kind, just checking the que DSN against the list on 
>the mounted tape.

So you are saying that as it reads the tape (after it has recalled a file from 
the tape) it sees the next file on the tape and checks if it is on the queue. 
It then either recalls the file (if it is on the
queue) or reads the tape to the next file and does the queue check again.

 From your "no sort" comment, I assume that it does not order the queue based 
on restore tape volume but just runs the full queue until it finds the dataset 
name or reaches the end of the queue. If the latter it seems inefficient since 
if the queue was ordered by volume serial number it could stop the scan once it 
reached an entry on a different tape.

--
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

IBM, id's to open pmr's, lot$a $$$$ now involved?...

[Brian France]

All,
 I'm surmising that y'all, like us, have multiple user id's for 
support at www.ibm.com/support. We have several people here that have 
opened PMR's over the past many many years. A couple of weeks back I 
went in to open an issue and found that I was no longer entitled to 
z/OS. What I found out was that only one person in my group could open a 
z/OS related PMR. After some questions to many IBM'ers my id was set 
back, no one knowing why the change had occurred. In trying to get the 
rest of my colleagues their access back I'm told that we will have to 
pay. That only my ID has Software Xcel and it's the basic. Well, yes, we 
knew that. Several years ago we opted to take it as the only id that 
could ask HOW to Support questions. Now I'm told that if all my 
colleagues are to have id's to open PMR's, which is 7 of us, that we 
would have to move to SoftwareXcel Enterprise and the quote is quite an 
eye popper.  So, long story short, I'm interested in the rest of ya... 
Any one seen this yet? Hell, even CA doesn't charge for userid's to open 
problem support records for software we are already paying support on.

--

--

Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu 

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

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

Re: DFHSM Recalls and Tape

[Hervey Martinez]

If you have CRQ(Common Recall Queue) set up, then HSM will "look ahead" and 
recall all files that are on the same tape. Also, with CRQ, you can limit which 
LPARS will perform recalls and limit them in that manner and all recalls will 
be routed to that LPAR. Otherwise, the recalls happen one at a time in a FIFO 
manner.

Regards,

Hervey

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert A. Rosenberg
Sent: Thursday, October 11, 2012 3:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Recalls and Tape

At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM Recalls and 
Tape:

>When it HSM finishes a recall, it checks the que in order for any 
>recall on the same tape.  When it reaches the end of the que, it 
>unmounts the tape, and starts recalling the first waiting dataset on 
>the que.  Haven't done as massive a quantity as 10,000 though.
>
>No sorting of any kind, just checking the que DSN against the list on 
>the mounted tape.

So you are saying that as it reads the tape (after it has recalled a file from 
the tape) it sees the next file on the tape and checks if it is on the queue. 
It then either recalls the file (if it is on the
queue) or reads the tape to the next file and does the queue check again.

 From your "no sort" comment, I assume that it does not order the queue based 
on restore tape volume but just runs the full queue until it finds the dataset 
name or reaches the end of the queue. If the latter it seems inefficient since 
if the queue was ordered by volume serial number it could stop the scan once it 
reached an entry on a different tape.

--
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: Slip trap for cross memory mode

[Peter Relson]

If running on z/OS 1.13, be sure that PTF UA64306 (APAR OA38669) is 
installed.

Peter Relson
z/OS Core Technology Design

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

Re: SLIP trap or some other possibility to DUMP on a given message text ?

[Lizette Koehler]

If you have an automation tool (OPS/MVS, Tivoli, SA390, etc...) then you
could trigger the dump with the automation product.  I think there maybe
something on the CBTTAPE.ORG called TSSO or similar.

I have not looked at the use of MSGID but there might also be some testing
in the SLIP code.  I am not sure.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Miklos Szigetvari
> Sent: Thursday, October 11, 2012 2:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SLIP trap or some other possibility to DUMP on a given message
text ?
> 
>  Hi
> 
> Can I set the SLIP TRAP on a given message content ?
> 
> I mean I can set the TRAP if MSGID=ICH408I, but I would need the dump only
if
> MSGID=ICH408I and the text contains a specific file or dataset name.
> 

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

Re: syslogd: FSUM1229 syslogd is already active

[IT Pro]

The least I could do was post the solution here.
Regards.

On Thu, Oct 11, 2012 at 12:10 PM, IT Pro  wrote:
> I completely agree, Peter.
> Thanks for your understanding.
> Aitor.
>
> On Wed, Oct 10, 2012 at 10:36 AM, Hunkeler Peter (KIUP 4)
>  wrote:
>>>Seeing that the message is quite misleading, yes it may deserve
>>>opening an APAR. I didn't think about it really. I have never opened
>>>an APAR before, but my boss won't be in the mood of my getting into
>>>the process of creating one. There's always work to be done, and I
>>>must not "waste time". I just obey (this doesn't mean IBM does not
>>>deserve getting warned about this to correct the manual).
>>
>> I perfectly understand your situation, however, you did waste a lot of
>> time just because the message was so misleading...
>>
>> It would be an APAR against the code not the manual. syslogd should
>> differentiate between the different reasons why it cannot proceed. At
>> least one additional (different) message would be appropriate.
>>
>> --
>> Peter Hunkeler
>>
>> --
>> 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: syslogd: FSUM1229 syslogd is already active

[IT Pro]

I completely agree, Peter.
Thanks for your understanding.
Aitor.

On Wed, Oct 10, 2012 at 10:36 AM, Hunkeler Peter (KIUP 4)
 wrote:
>>Seeing that the message is quite misleading, yes it may deserve
>>opening an APAR. I didn't think about it really. I have never opened
>>an APAR before, but my boss won't be in the mood of my getting into
>>the process of creating one. There's always work to be done, and I
>>must not "waste time". I just obey (this doesn't mean IBM does not
>>deserve getting warned about this to correct the manual).
>
> I perfectly understand your situation, however, you did waste a lot of
> time just because the message was so misleading...
>
> It would be an APAR against the code not the manual. syslogd should
> differentiate between the different reasons why it cannot proceed. At
> least one additional (different) message would be appropriate.
>
> --
> Peter Hunkeler
>
> --
> 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: SLIP trap or some other possibility to DUMP on a given message text ?

[Binyamin Dissen]

On Thu, 11 Oct 2012 11:25:53 +0200 Miklos Szigetvari
 wrote:

:>Can I set the SLIP TRAP on a given message content ?

:>I mean I can set the TRAP if MSGID=ICH408I, but I would need the dump 
:>only if MSGID=ICH408I and the text contains a specific file or dataset 
:>name.

At SLIP entry R3 points to the major message and R5 to the minor message. So
you can use a DATA qualifier for specific columns in the message.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Slip trap for cross memory mode

[Ron MacRae]

Chuck,
  I don't think your product, or any other real time debugger, wouldn't 
help in our situation.  

1) The problem we are trying to debug is happening on our customer's production 
system. The system recovers as best it can and continues to run but we don't 
take a dump. They cannot reproduce it in test, neither can we.

2) The problem is volume and timing related and only happens in a heavily 
stressed system that is running with multiple full blown zIIPs and a couple of 
very slugged CPs. The minimal housekeeping on the CP doesn't seem to be keeping 
up with the work being done on the zIIPs.

Thanks to Jim Mulder I've now got a slip I can try.  I just hope the slip being 
active doesn't change the timing such that the problem doesn't happen.

Ron.

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

Re: Slip trap for cross memory mode

[Ron MacRae]

Jim,
 Your suggestion almost worked.  Neither the home or primary AS alone were 
enough to cause the slip to fire. I found the cross memory IF slip fired only 
if I added BOTH asids to the slip as follows -

SLIP SET,IF,ID=RJM1,ACTION=SVCD,ASID=(asid-of-STC2. asid-of-STC1), 
PVTMOD=(module,offset,offset),END

This could get complex as there are quite a few different home ASs that can PC 
into the single primary AS, I guess I can just add them all to the ASID list?

Does that mean if I have say a singal primary and 5 possible home ASs listed it 
will dump all 6 or just the hone and primary at the time of the slip?

Thanks for the pointer in the right direction.

Ron.

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

Re: Slip trap for cross memory mode

[Ron MacRae]

Ray,
  Thanks for the idea, however it's not practical.  The program is loaded 
in the primary address space by the primary AS program using attach and the 
actual address varies. I could take a dump after it's loaded to find out where 
it is but this is being done by one of our customers who might have difficulty 
with IPCS etc.

However it's a usefullthought if we get really desperate.

Ron.

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

SLIP trap or some other possibility to DUMP on a given message text ?

[Miklos Szigetvari]

Hi

Can I set the SLIP TRAP on a given message content ?

I mean I can set the TRAP if MSGID=ICH408I, but I would need the dump 
only if MSGID=ICH408I and the text contains a specific file or dataset 
name.


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

Re: DFHSM Recalls and Tape

[Robert A. Rosenberg]

At 20:58 -0500 on 10/10/2012, Mike Schwab wrote about Re: DFHSM 
Recalls and Tape:



When it HSM finishes a recall, it checks the que in order for any
recall on the same tape.  When it reaches the end of the que, it
unmounts the tape, and starts recalling the first waiting dataset on
the que.  Haven't done as massive a quantity as 10,000 though.

No sorting of any kind, just checking the que DSN against the list on
the mounted tape.


So you are saying that as it reads the tape (after it has recalled a 
file from the tape) it sees the next file on the tape and checks if 
it is on the queue. It then either recalls the file (if it is on the 
queue) or reads the tape to the next file and does the queue check 
again.


From your "no sort" comment, I assume that it does not order the 
queue based on restore tape volume but just runs the full queue until 
it finds the dataset name or reaches the end of the queue. If the 
latter it seems inefficient since if the queue was ordered by volume 
serial number it could stop the scan once it reached an entry on a 
different tape.


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