Re: Allocation mystery

[Gibney, Dave]

There is a parmlib option to abend NOT CATLG 2. I recommend using it.

IMO, SMS should be set up for all allocations and the fallback pathway to 
storage volumes blocked. Back in the "old days", we did experience the scenario 
you describe. After the same dataset name appeared on all available volumes, 
then the abend would occur.

I am also a strong believer in the philosophy "If it ain't cataloged, it 
doesn't exist". I feel free to whack any such I find in the application storage 
pools. They have always (so far) been the result of an error. 

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Tom Marchant
> Sent: Thursday, May 31, 2012 2:38 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Allocation mystery
> 
> On Thu, 31 May 2012 15:25:04 -0600, Steve Comstock wrote:
> 
> >I run a job that creates a new data set using
> >this DD statement:
> >
> >//NEWMASTDD  DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
> >//   LIKE=STNT329.TRAIN.ZINPUTA
> >
> >Job runs fine and creates the new file.
> 
> Is the data set SMS managed?
> 
> >Now I run it again; I expect it to fail with 'DUPLICATE
> >DATA SET NAME' - but it doesn't. Instead, it goes ahead
> >and allocates the file on a storage volume and gives me
> >a zero completion code; just doesn't catalog the data
> >set.
> 
> Storage volume suggests that it is allocated to a non-managed
> volume.  This is not unusual.  Did you receive a NOT CATLGD 2
> message?
> 
> --
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Spool offload

[Gibney, Dave]

Change them dynamically via commands. Then update JES2PARm to match.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of R.S.
> Sent: Monday, May 28, 2012 11:24 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Spool offload
> 
> W dniu 2012-05-28 18:03, Skip Robinson pisze:
> > OK, I'll bite. Which parameters cannot be changed dynamically? I
> think
> > you mentioned in another thread about having to resolve name
> > conflicts. There ways to juggle things around via multiple
> incremental
> > changes to achieve the desired result. I have systems last cold
> started in 1995.
> 
> What IBM writes in JES2PARM:
> /*
> /*
> /*  NOTE: Changing ANY of the following parameters will prevent a
> /*JES2 Warmstart; they can ONLY be changed on a COLDSTART
> /*
> /*
> /*
> /*  CKPTDEF   DSNAME=
> /*  JOBDEFJOBNUM=
> /*  NJEDEFOWNNODE=
> /*  OUTDEFJOENUM=
> /*  SPOOLDEF  BUFSIZE=, DSNAME=, RECINCR=, SPOOLNUM=, TGNUM=,
> /*TRKCELL=, VOLUME=
> /*  TPDEF RMTNUM=
> /*
> 
> I know I can change the parameters (some of them , at least)
> dynamically, by a command.
> In my case I changed JOBNUM, JOENUM (and some others).
> 
> Changing it dynamically causes some discrepancy between JES2PARM and
> reality, and can be confusing across IPLs.
> In my case there was no problem with IPL, and even spool content was in
> "nice to have" category, so the cold start wasn't big issue.
> 
> Disclaimer: I'm not JES2 specialist, so I'd be happy to hear that I
> could do it in other, smarter way.
> 
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> P.S. Thank you Mark and Skip for your help! I appreciate it.
> 
> 
> 
> 
> --
> Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
> przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by
> jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie
> jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do
> jej przekazania adresatowi, informujemy, e jej rozpowszechnianie,
> kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze
> jest prawnie zabronione i moe by karalne. Jeeli otrzymae t
> wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc
> odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej
> kopie wydrukowane lub zapisane na dysku.
> 
> This e-mail may contain legally privileged information of the Bank and
> is intended solely for business use of the addressee. This e-mail may
> only be received by the addressee and may not be disclosed to any third
> parties. If you are not the intended addressee of this e-mail or the
> employee authorised to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail
> by mistake please advise the sender immediately by using the reply
> facility in your e-mail software and delete permanently this e-mail
> including any copies of it either printed or saved to hard drive.
> 
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00
> 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd
> Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru
> Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-
> 88.
> Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w
> caoci wpacony) wynosi 168.410.984 zotych.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: REPRO MERGECAT performance

[Gibney, Dave]

  In the spirit of evenhandedness, faster mergecat is one of the good reasons 
to acquire T-Rexx from Dinosoft, or the other one :)

Dave Gibney
Information Technology Services
Washington State University

> On May 25, 2012, at 11:02 AM, Mary Anne Matyaz wrote:
> 
> > Can MERGECAT performance be improved by altering the buffer space
> > values for either the input or output catalog, or both?
> >
> > If you have a lot of VSAM, probably not. As I recall, doing a large
> > repro mergecat with a lot of VSAM was very slow, but it was mostly
> > due to the need to go change every vvds entry.
> >
> > In other words, I don't think you'll get a lot of bang for your buck.
> >
> > Mary Anne
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Masking Numeric Keys

[Gibney, Dave]

Surely you don't actually use all billion values. 

> 
> 
> John, this is actually kinda like my plan B.  A real identifier of
> value N would be translated to be the Nth value in a sequence of
> pseudo-random numbers.  The only problem is maintaining a billion row
> table.  I have thought of asking our security officer if I can get away
> with only masking the last six digits of the identifier, leaving the
> first three ASIS.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Early IPL problems

[Gibney, Dave]

I have heard two good suggestions.
1. Add an aid to the HMC to access the Wait State code documentation.
2. ZZSA equivalent easily invoked via HMC (or SE) as fix of last resort :)

Once, after final recabling of a DASD move, we had one mistake in LOADxx. It 
did take opening an incident with IBM to fully diagnose. We were about to 
recable back, when I remembered the CD Sam K. gave out at SHARE. Flipped the 
equivalent of 2 bits in one character and there was dancing in the machine room.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of John McDowell
> Sent: Monday, May 14, 2012 11:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Early IPL problems
> 
> Just to be clear.
> 
> My intent is to get a sampling of customer experience in the titled area,
> specifically to gauge real world experiences.
> 
> If you see no need for any changes in the z/OS system behavior in this area
> that is fine, on the other hand if you would like to see some different
> behavior I am interested in hearing what that might be.
> 
> John McDowell - IBM
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: It's feeding time in Jurassic Park . . .

[Gibney, Dave]

The "wisdom" of Anton (Kerneels here) is generally well mixed in with much that 
is superfluous to the actual conversation.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Scott Ford
> Sent: Friday, May 04, 2012 1:35 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: It's feeding time in Jurassic Park . . .
> 
> Aren't we here to help colleagues who need the help and assistance ?
> I understand there's a fine line between eloping and be used bad abused
> ..been there done that haver numerous tshirts
> 
> 
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> 
> 
> On May 4, 2012, at 3:12 PM, Kerneels de Wet
>  wrote:
> 
> > No disrespect but this looks a little like what the "Fox channel" dishes up
> for us on a daily basis:
> >
> > a) You post a message on IBMMAIN stating that you are starting a project
> but have no idea how to do it
> > b) You use a nameless email account with a cellphone number listed as
> Poughkeepsie , NY
> > c) The SHARE grease monkeys immediately respond with "YOU are doing
> what ? You need to come talk to us "
> > d) The Health Care BIG spender responds with "My management wants to
> go the other way"
> >
> > Note: If it smells like a duck, quacks like a duck, looks like a duck, and 
> > walks
> like a duck...it should be on the FOX channel
> >
> > Kerneels
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: IBMLink Outage May 4-7

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Edward Jaffe
> Sent: Wednesday, May 02, 2012 4:11 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IBMLink Outage May 4-7
> 
> On 5/2/2012 3:35 PM, Gibney, Dave wrote:
> > With the new ERP system they are moving us to, scheduled outages of this
> length are routine. :( but it's better than the working legacy :)
> 
> Double standard.

New regime, "New Direction" 

I'll need plan B (or C) before I retire. It has been a mostly good 30 years 
here.

Dave Gibney
Information Technology Services
Washington State University> 
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> 310-338-0400 x318
> edja...@phoenixsoftware.com
> http://www.phoenixsoftware.com/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: IBMLink Outage May 4-7

[Gibney, Dave]

In all the time I've been doing this, I would never have dared ask for outages 
of this magnitude. The worst I ever was part of was a couple 12-14 hour 
unexpected weekend days when we didn't have fall back ready. I think that was 
also the time after VM and before we did a sandbox LPAR, so we did some 
standalone restores.

With the new ERP system they are moving us to, scheduled outages of this length 
are routine. :( but it's better than the working legacy :)

Dave Gibney
Information Technology Services
Washington State University

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

Re: ServerPac RACF* jobs (rant)

[Gibney, Dave]

I'll bite. Hi, Walt, What makes you think IBM might listen to this now that you 
are not there? These jobs have always been a mess. 

Last time I ranted, I suggested that serverpac provide an unload (or unload 
records of the required profiles that could be used with DBSYNC (A very useful 
tool, thank you so much) to more closely approximate the updates needed to a 
customer specific RACF DB.
I think Russ, or someone took the idea under advisement.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Walt Farrell
> Sent: Friday, April 27, 2012 11:32 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: ServerPac RACF* jobs (rant)
> 
> On Fri, 27 Apr 2012 17:57:52 +0200, R.S.
>  wrote:
> 
> >RACFDRV and RACFTGT jobs are part of ServerPac installation process.
> >I have the following observation: the jobs are longer and longer and
> >MUCH MORE STUPID.
> >Example:
> >...snipped...
> >BTW: I corrected (you can call it: edited) RACFDRV. Original size: 1500
> >lines, size after corrections: 137 lines (including comments), almost no
> >line left untouched.
> >Now I'm editing RACFTGT. 4300+ lines, I edited maybe 50%, 1600 lines left.
> >
> >I think this should be seriously improved.
> >
> >
> >Time for my pills
> 
> Perhaps better, time for you to open a PMR with the IBM Support Center
> (directed to ServerPac, of course, not RACF) so they can improve things.
> 
> --
> Walt
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Have you ever done this using FTP?

[Gibney, Dave]

z/OS to z/OS, the z/OS extension MGET should work :) It's when you 
park/pass-through the squatty box that it gets more picky. 

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Lizette Koehler
> Sent: Thursday, April 26, 2012 3:08 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Have you ever done this using FTP?
> 
> >
> >FTP a PDS from one Mainframe to another mainframe connected through
> TCPIP?
> >
> >If so how is it done?
> >
> >
> >
> >John Norgauer
> 
> I typically either use TRSMAIN, TSO XMIT, or DFDSS to dump the PDS to a seq
> file, then do the FTP.
> 
> I think TRSMAIN can actually have the PDS as input and produce the seq file
> as output.
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT ALLOCATION.

[Gibney, Dave]

This is a good point. I wonder what brought this DSN to Esmie's attention?
Is it usable by the application it is part of?

I would wager if it doesn't migrate/recall, it also won't backup/recover 
usefully either.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Tom Marchant
> Sent: Thursday, April 26, 2012 2:27 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT
> ALLOCATION.
> 
> On Thu, 26 Apr 2012 20:48:48 +, Gibney, Dave wrote:
> 
> >Migrate/recall it and it might get better.
> 
> I wouldn't do that without first taking a full volume backup.
> 
> --
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT ALLOCATION.

[Gibney, Dave]

What level of z/OS? I vaguely remember when ISPF hadn't caught up with newer PS 
formats.

Migrate/recall it and it might get better.



Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Bill Fairchild
> Sent: Thursday, April 26, 2012 11:31 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT
> ALLOCATION.
> 
> Being able to reproduce the incorrect display long after any DSCBs were
> being updated indicates that this is not due to a timing problem when
> reading the DSCBs.  I suggest you get IBM involved, either through an ETR or
> an APAR.
> 
> Bill Fairchild
> Programmer
> Rocket Software
> 408 Chamberlain Park Lane . Franklin, TN 37069-2526 . USA
> t: +1.617.614.4503 .  e: bfairch...@rocketsoftware.com . w:
> www.rocketsoftware.com
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of esmie moo
> Sent: Thursday, April 26, 2012 1:27 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT
> ALLOCATION.
> 
> Here is the display after I hit ENTER
> 
>   Data Set Information
>   Command ===>
> 
>   Data Set Name . . . .
> : ZWA6PWG.ICOD.DMSC.D2012087.T130018
> 
>  General Data   Current Allocation
>   Management class . . : **None**    Allocated tracks  . : 3,222
>   Storage class  . . . : **None**Allocated extents . :  12
>   Volume serial . . . : A24U90
>   Device type . . . . : 3390
>   Data class . . . . . : **None**
>   Organization  . . . : PS  Current Utilization
>   Record format . . . : U   Used tracks . . . . : 
> 12,596
>   Record length . . . : 0  Used extents  . . 
> . : 3
>   Block size  . . . . : 27998
>   1st extent tracks . : 1074
>   Secondary tracks  . : 1074   Dates
>   Data set name type  :   Creation date . . . 
> : 2012/03/27
>   SMS Compressible. . : NO  Referenced date . . : 
> 2012/04/26
>   
> Expiration date . . : ***Perm***
> 
> 
> 
> 
> From: esmie moo 
> To: IBM-MAIN@bama.ua.edu
> Sent: Thursday, April 26, 2012 2:20:50 PM
> Subject: Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT
> ALLOCATION.
> 
> Once the dsn is displayed by ISPF, I then typed I as shown below:
> 
> Command - Enter "/" to select
> action  Message   
> Volume
> ---
> IZWA6PWG.ICOD.DMSC.D2012087.T130018 
>  A2
> 4U90
> * End of Data Set list
> * **
> 
> 
> 
> 
> From: Bill Fairchild 
> To: IBM-MAIN@bama.ua.edu
> Sent: Thursday, April 26, 2012 2:13:52 PM
> Subject: Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT
> ALLOCATION.
> 
> Please describe more precisely what you did when you said you "typed I
> beside the dsn".
> I tried to type the number 1 and the letter I beside a dsn on an ISPF 3.4
> screen and I did not get any display like yours.
> 
> Bill Fairchild
> Programmer
> Rocket Software
> 408 Chamberlain Park Lane . Franklin, TN 37069-2526 . USA
> t: +1.617.614.4503 .  e: bfairch...@rocketsoftware.com . w:
> www.rocketsoftware.com
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of esmie moo
> Sent: Thursday, April 26, 2012 1:07 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT
> ALLOCATION.
> 
> Bill,
> 
> In my first e-mail, I displayed the dsn the following way:
> 
> ISPF 3.4
> ZWA6PWG.ICOD.DMSC.D2012087.T130018
> Next, I typed I besided the dsn
> Then it displayed me the dsn stats.
> 
> 
> 
> From: Bill Fairchild 
> To: IBM-MAIN@bama.ua.edu
> Sent: Thursday, April 26, 2012 1:48:44 PM
> Subject: Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT
> ALLOCATION.
> 
> The display you show below only displays the first 3 extents, which have a
> total of 3*1074=3222 tracks, which is what your previous email said was the
> total of all tracks allocated.  This display also shows a non-zero pointer to 
> a F3
> DSCB in which will be described up to 13 more extents of which your data set
> will have non-zero values in the first 9, for a grand total of 12*1074=12888
> tracks.  The last block pointer in the display below agrees with the number of
> tracks utilized in your previous email.  It appears that for some reason th

Re: Why does Enterprise COBOL V4.1 optimization complain about a PERFORM loop?

[Gibney, Dave]

Dropping through into PARA-2 from PARA-1 when the return from the PERFORM 
PARA-2 is still set would result in a loop. Ugly code IMO.

Dave Gibney
Information Technology Services
Washington State University

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Bob Shannon
> Sent: Monday, April 23, 2012 12:46 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Why does Enterprise COBOL V4.1 optimization complain about a
> PERFORM loop?
> 
> > Can anyone explain to me why I get Enterprise COBOL V4.1 "informational"
> message IGYOP3094-W >in the do-nothing program listed below?
> 
> I haven't written in COBOL in over 30 years, but I suspect it's because SUB-
> PARA-2 sits in between SUB-PARA-1 and PARA-EXIT.
> 
> 44SUB-PARA-1.
>   45IF WS-SUB < 6
>   46  1MOVE 0 TO WS-SUB
>   47  1GO TO PARA-EXIT.
>   48
>   49SUB-PARA-2.
>   50DISPLAY WS-SUB.
>   51
>   52PARA-EXIT.
>   53EXIT.
> 
> Bob Shannon
> Rocket
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: GO TO "cobol"

[Gibney, Dave]

A dirty myth about COBOL is the belief the THRU is required and that SECTIONs 
are a good idea. Unless specifically required by SORT or something, I never 
used either. It has been 20+ years since I did much COBOL. Haven't had the 
pleasure of the newer constructs.

As to the OP's belief about performance, structured programming has never been 
about performance, it is about understandability.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of McKown, John
> Sent: Monday, April 16, 2012 5:28 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: GO TO "cobol"
> 
> Our use of GO TO is generally restricted to usage such as:
> 
>PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
> 
> I-P.
> READ FILE AT END
>  SET CONDITION TO TRUE
>  GO TO I-P-EXIT
> END-READ
> ...
> I-P-EXIT.
> EXIT.
> 
> Otherwise, to avoid the GO TO, we'd need to do:
> 
> I-P.
> READ FILE AT END
>  SET CONDITION TO TRUE
> END-READ
> IF NOT CONDITION THEN
> ...
> END-IF.
> I-P-EXIT.
> EXIT.
> 
> Which I consider to be worse than the exit, so far as comprehension is
> concerned.
> 
> --
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets®
> 
> 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® is the brand name for products underwritten and issued by
> the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life
> Insurance Company®, Mid-West National Life Insurance Company of
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg
> > Sent: Monday, April 16, 2012 5:40 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: SV: GO TO "cobol"
> >
> > An alternative is to have e g an 88-type LEAVE item that is
> > checked for every code-block including all iterations and selections.
> > (You set leave to true when wanting to do a "leave" type jump.)
> >
> >
> >
> > Regards,
> > Thomas Berg
> > __
> > Thomas Berg   Specialist   AM/DQS   SWEDBANK AB (publ)
> >
> >
> >
> > > -Ursprungligt meddelande-
> > > Från: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@bama.ua.edu] För
> > > Edward Jaffe
> > > Skickat: den 16 april 2012 08:15
> > > Till: IBM-MAIN@bama.ua.edu
> > > Ämne: Re: GO TO "cobol"
> > >
> > > On 4/15/2012 10:31 PM, Wayne Bickerdike wrote:
> > > > For devotees of Jackson Structured programming, the GOTO
> > is a must for
> > > > POSIT and ADMIT processing. Otherwise it can be messy
> > avoiding a GOTO.
> > >
> > > The problem with GOTO is that the suitability of the target branch
> > > location is
> > > not enforced by the compiler according to any structured discipline.
> > >
> > > Premature terminations (posit/quit/admit) can almost always
> > be handled
> > > with
> > > LEAVE-type statements or immediate return from a subroutine. Some
> > > languages have
> > > SIGNAL, EXIT, etc. which can help provide structured premature
> > > termination for
> > > larger routines without resorting to the dreaded GOTO.
> > >
> > > --
> > > Edward E Jaffe
> > > Phoenix Software International, Inc
> > > 831 Parkview Drive North
> > > El Segundo, CA 90245
> > > 310-338-0400 x318
> > > edja...@phoenixsoftware.com
> > > http://www.phoenixsoftware.com/
> > >
> > >
> > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Secure FTP (Was: z/OS every two years)

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of John McKown
> Sent: Saturday, April 14, 2012 1:16 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Secure FTP (Was: z/OS every two years)
> 
> On Sat, 2012-04-14 at 00:54 +, Gibney, Dave wrote:
> > > -Original Message-
> 
> >
> > And, I've always found FTPS (granted no client identification certs yet)
> easier.
> > None of that USS , sometimes called OMVS, perhaps properly called z/OS
> > Unix System Services, involved :)
> >
> > Actually, I recently finished a sporadic effort to automount /u using ZFS.
> Now I can manage user's data in the zUnix arena.
> > I may get back to trying ssh/sftp someday.
> 
> If you implement the freely available SSH enhancements from Dovetailed
> Technologies, their sftp server can access the same z/OS legacy datasets and
> SPOOL (get to read a job's output, put to submit a job) as FTP.
> 
> http://dovetail.com .
> 
> Not only is the basic code free, you don't even need to "register" with them
> to download it. Literally "no questions asked!" Just download and
> implement. And it's fairly simple. If you want support, you can get that with 
> a
> support contract.

I looked at that more than once. I honestly don't remember what, if any, 
impediment stopped me for that route. Maybe merely time. Probably incomplete 
configuring of Ported Tools. :) I'll look again if I get a chance, but I think 
I'm even more of a one man show than you are. Currently I have to deal with our 
disk array going EOSL end of June by surprise. It's possible that the vendor 
did notify the guy who left abruptly, but I don't know.

> 
> >
> > Dave Gibney
> > Information Technology Services
> > Washington State University
> >
> 
> --
> John McKown
> Maranatha! <><
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Secure FTP (Was: z/OS every two years)

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Edward Jaffe
> Sent: Friday, April 13, 2012 5:23 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Secure FTP (Was: z/OS every two years)
> 
> On 4/13/2012 5:04 PM, Art Gutowski wrote:
> > I see.  Anyone else share in Mary Anne's sentiment?  In other words, is
> FTPS (or SFTP?) as much a requirement/priority notwithstanding the
> impending ShopzSeries / RECEIVE ORDER requirement?  If so, and you can
> respond, please drop me a line off-list.  Nothing detailed... just curious.
> 
> We have customers that insist on 'secure' FTP for sending dumps,
> downloading
> files, etc. We set up an SFTP server on our public Internet site and that 
> seems
> to have satisfied all requirements thus far. We don't currently support FTPS
> with x.509 certificates. Hopefully, we'll never be asked to do so. It's a 
> PITA.

And, I've always found FTPS (granted no client identification certs yet) easier.
None of that USS , sometimes called OMVS, perhaps properly called z/OS Unix 
System Services, involved :)

Actually, I recently finished a sporadic effort to automount /u using ZFS. Now 
I can manage user's data in the zUnix arena.
I may get back to trying ssh/sftp someday.

Dave Gibney
Information Technology Services
Washington State University

> 
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> 310-338-0400 x318
> edja...@phoenixsoftware.com
> http://www.phoenixsoftware.com/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: New z/OS 1.13 Health Checks - Friday Rant

[Gibney, Dave]

   I run monoplexs. Like I expect most other small shops.
   4 LPARS, only shared DASD, no CTC connections. There are TCPIP Hipersocket 
links, but as far as I know, XCF is not aware of these links.  What/Who are the 
typical users of XCF signaling in a monoplex. How would I know if they are 
experiencing degraded or inefficient signaling?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Vernooij, CP - SPLXM
> Sent: Saturday, March 31, 2012 2:40 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: New z/OS 1.13 Health Checks - Friday Rant
> 
> "R.S."  wrote in message
> news:<4f776fe9.80...@bremultibank.com.pl>...
> > W dniu 2012-03-30 16:24, Mark Brooks pisze:
> > > Hi,
> > >   The XCF signalling services are available in all sysplex
> > > environments, including monoplex.  The rationale that motivates the
> > > defining of transport classes applies to them all.
> >
> > What for?
> > The classes are for traffic on sysplex links, are they?
> > No links, no need for traffic priorities.
> >
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> 
> Read well: they are for XCF signalling links. Keep a couple of things
> separated:
> 1. XCF signalling is used between members that connect to an XCF group.
> The advantage is that the members don't have to worry where the other
> members are and how to reach them. XCF will take care of that.
> 2. A members can be anywhere in a sysplex, so also on the same LPAR.
> This means that XCF signalling is used/usable in a monoplex and that is why
> signalling control and tuning is needed in any sysplex, also a monoplex.
> 3. XCF will communicate via XCF signalling paths, which are internal within 
> the
> lpar and via CF structures and/or CTC connections between LPARs and
> machines.
> 
> So, classes are not for sysplex links, but for XCF transportation. Maybe XCF
> decides to sends messages over sysplex links, maybe not.
> 
> Kees.
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If you
> are not the addressee, you are notified that no part of the e-mail or any
> attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may be
> unlawful. If you have received this e-mail by error, please notify the sender
> immediately by return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission of
> this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Relocating files in custompac - Z1.13

[Gibney, Dave]

For DLIBs, I change them all to SMS and let them land where they may in the 
pool.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Kathleen Mclaughlin
> Sent: Thursday, March 29, 2012 10:11 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Relocating files in custompac - Z1.13
> 
> Hello Matt,
> 
> To move specific datasets to different PVOLs, my suggestion is to change
> them by their high level qualifier (HLQ).  From the Modify System Layout
> Panel:
>   select option "C" - View and change datasets by selected attributes
>   select "HLQ"
>   select the HLQ you want to work with
>   issue the "CH PVOL DLIB newvol" command
>   exclude all the datasets you do not want to move to the new volume
>   pf3 out of the global change panel
> 
> Good Luck
> 
> Kathleen McLaughlin
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Dazzo, Matt
> Sent: Thursday, March 29, 2012 8:34 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Relocating files in custompac - Z1.13
> 
> I am working in the modify system layout panels. I have a 3390-9 being used
> for the dlib libraries and need to relocate some files to a second volume
> because the mod-9 is full. According to the good old book you have to go to
> the SUMMARY Of Logical Volumes, select the LV and then you can change
> the PVOL, the problem is it changes every (411 of them) dsn's in the LV. I
> have NOT found a way to change only specific dsn's. Please tell me there is a
> simple solution that I missed.
> 
> Thanks Matt
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: rexx cpu intensive

[Gibney, Dave]

I wasn't the original author who did, as others have described with the epithet 
"you can write FORTRAN in any language"
Vol.i = '012345'
Dsn.i ='file.name.here'
Cdate.i = 
Etc.
 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Dana Mitchell
> Sent: Thursday, March 22, 2012 7:41 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: rexx cpu intensive
> 
> Dave,
> 
> I don't completely understand what you changed here.   Do you mean the
> 'after'  code was something like this:
> 
> vol = '012345'
> dsn.vol = 'file.name.here'
> 
> What were you using 'before'?
> 
> Dana
> 
> On Wed, 21 Mar 2012 19:53:34 +, Gibney, Dave 
> wrote:
> 
> >I once greatly improved a Rexx routine exploiting the associative
> Rexx array. It was some extract from a TMS report. It was originally
> written like any other array with a subscript variable. And a lot of
> for loops.
> >   I changed it to use the main key (in this case the tape volser) as
> the index. Elapsed and CPU times where reduced 80 to 90 percent.
> >
> >Dave Gibney
> >Information Technology Services
> >Washington State University
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: rexx cpu intensive

[Gibney, Dave]

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, March 21, 2012 1:33 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: rexx cpu intensive
> 
> On Wed, 21 Mar 2012 19:53:34 +, Gibney, Dave wrote:
> 
> >I once greatly improved a Rexx routine exploiting the associative Rexx
> array. It was some extract from a TMS report. It was originally written like 
> any
> other array with a subscript variable. And a lot of for loops.
> >   I changed it to use the main key (in this case the tape volser) as the 
> > index.
> Elapsed and CPU times where reduced 80 to 90 percent.
> >
> Yes, but one must sometimes contend with readers of these
> lists who insist that Rexx compound tails _must_ be consecutive
> positive integers, and the count _must_ appear in the .0 member,
> because that's the way the only example they read did it.
> 

Much of my growth in this field has been slow and steady.
The Rexx associative array  realization is one of the "aha moments" I still 
remember. 

What I'd really like (is it there and I don't know?) is a:  
for "each" stem_var.
   say "each"
   if each = 
   other_stem.each = 'foo'
  etc.



Dave Gibney
Information Technology Services
Washington State University

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

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

Re: rexx cpu intensive

[Gibney, Dave]

I once greatly improved a Rexx routine exploiting the associative Rexx 
array. It was some extract from a TMS report. It was originally written like 
any other array with a subscript variable. And a lot of for loops.
   I changed it to use the main key (in this case the tape volser) as the 
index. Elapsed and CPU times where reduced 80 to 90 percent.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Jonathan Goossen
> Sent: Wednesday, March 21, 2012 9:13 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: rexx cpu intensive
> 
> Look at your code design and remember that REXX arrays are associative.
> Every access to an array element is a search for the full variable name
> with the index as part of the name.
> 

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

Re: Execution Velocity

[Gibney, Dave]

That is a very high, IMO, goal for batch. I would expect very little besides 
the system to have a higher priority.
Does you Critical path use this HOTBATCH?
How multi-threaded is your critical path? If 4 jobs don't run parallel, then 
the 4th CP is doing other work and you may find the answer is just the 
additional overhead switching another CP.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Tom Marchant
> Sent: Tuesday, March 20, 2012 12:17 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Execution Velocity
> 
> On Tue, 20 Mar 2012 11:05:25 -0500, gsg wrote:
> 
> >Can someone please explain execution velocity for Workload Manager, I'd
> really appreciate it.
> 
> John Arwe's paper, for which Alan posted a link is excellent.
> 
> >We do not seem to be getting the results we thought we
> >would.  On this particular LPAR, we we're running with 3CPs,
> >but when we activated a 4th CP, our critical path ran longer.
> >Overall we are pushing through more work, but our critical
> >path window ran longer.  We are stumped on why.  We're
> >starting to look at RMF data, but thought I would throw it
> >out to see if anyone has any clues.
> 
> Clues come from RMF data about how your goals are being met.
> 
> >We have a HOTBATCH service class defined with IMP=1,
> >Execution Velocity of 90, with the CPU Critical flag turned
> >on.  This service class has a jobclass assigned to it.  At
> >any given time during our batch window, there may be up
> >to two of three of these jobs running.  Other service class
> >we have define for batch are PRDBATHI(IMP=2, Execution
> >Velocity of 30) and PRDBATLO(Discretionary).
> 
> It sounds as if you have turnaround time requirements for
> these jobs.  IMO, velocity goals are not the best for this kind
> of workload.  Have you considered response time goals?
> 
> --
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Theology question

[Gibney, Dave]

I think (hope) you mean two single quotes '
Not a double quote "

Are you asking how to document or how to code the parameter or how to code the 
interpretation of the parameter?

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Thomas Kern
> Sent: Monday, March 19, 2012 2:41 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Theology question
> 
> I feel the asterisk should mean "use the global default" and the '' should
> mean "don't use
> any value".
> 
> /Tom Kern
> 
> On 3/19/2012 17:12, Phil Smith wrote:
> > In our configuration data set, you can specify a default, global value for
> something. Specific entries in the configuration can override that global
> value. However, there are cases where you *must* specify a null value on a
> specific entry, as if you had no default, global value.
> >
> > Our internal debate is over whether an asterisk is appropriate to say "No,
> really, don't use any value here".
> >
> > So examples might be:
> >
> > thing1(option1,option2)  /* This defines a thing with an explicit option1 
> > and
> explicit option2 */
> >
> > thing2(option1)  /* This defines another thing and says "use the default,
> global value for option2 if you have one" */
> >
> > thing3(option1,*)  /* This would define another thing and say "even if you
> have a default, global value for option2, pretend you don't" */
> >
> > thing4(option1,'')  /* This is an alternative form of thing3 */
> >
> > One of us feels that the asterisk should mean "use the global default". One
> of us feels that the double quote is ugly and error-prone.
> >
> > Based on the collective wisdom of the centuries, what *feels* right to you?
> > --
> > ...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...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Performance question

[Gibney, Dave]

IBM markets something called a zAAP specifically to allow Java access to an 
unrestricted CP that isn't subject to z/OS and other ISV Software charges. 
Should be 'nuff said :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Scott Ford
> Sent: Thursday, March 15, 2012 12:31 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Performance question
> 
> All,
> 
> I heard art one time on z/os that java was well sort of a performance
> hog..not talking in Unix Systems Services...is it true and what release did it
> change, if it did ...
> 
> Sent from my iPad
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Hypothetical Performance Question

[Gibney, Dave]

Between little and none :) IMHO

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Kent Ramsay
> Sent: Thursday, March 15, 2012 12:12 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Hypothetical Performance Question
> 
> Hi,
> 
> A hypothetical question but first the setting: A customer has two jobs auto-
> submitted within five minutes of each other. Job 1 grabs the dozen or so data
> sets and executes, leaving Job 2 with a formal "waiting for data sets"
> situation. Obviously, when Job 1 finishes, Job 2 actually starts. Now the
> question: While Job 2 is queued up waiting for the data sets, is there any
> appreciable use of CPU by z/OS or JESx services to continually check to see if
> the data sets are free, yet? In this case, Job 1 runs for almost 4 hours so
> Allocation services is checked at least occasionally. I'm not interested in 
> doing
> a charge-back, just wondering if there's any real cpu usage.
> 
> Since this cropped up, the customer has changed the job schedule to submit
> Job 2 after Job 1 completes but the mind wonders. Thanks.
> 
> Kent
> 
> Kent Ramsay
> 425.681.2278
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Endevor(Change Management Software)

[Gibney, Dave]

We use Endevor for application change management. Some of our routine system 
monitoring, and backups are jobs managed by Endevor. 

IMO, Endevor is not suited for system change management. There are products 
that are, but they are expensive.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of gsg
> Sent: Wednesday, March 14, 2012 10:29 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Endevor(Change Management Software)
> 
> Is anyone out there using CA-Endevor?  Do you manage your system changes
> using Endevor?  If so, how are you doing this and was it hard to setup?
> 
> We are looking into this, but there are so many system libraries that could be
> changed, it needs a lot of thought to get it right.
> 
> Thanks
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Server time Protocol and CICS

[Gibney, Dave]

F cicsjobn,CEMT PERFORM RESET

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of John Norgauer
> Sent: Monday, March 12, 2012 3:50 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Server time Protocol and CICS
> 
> This weekend we had our mainframe time automatically adjusted to Day
> Light
> Time using S.T.P.. However, CICS did not get the time
> changed automatically. Is CICS still unable to do this(have the time
> changed automatically)?
> 
> 
> 
> John Norgauer
> Senior Systems Programmer
> Mainframe Technical Support Services
> University of California Davis Medical Center
> 2315 Stockton Blvd
> ASB 1300
> Sacramento, Ca 95817
> 916-734-0536
> 
>  SYSTEMS PROGRAMMING..  Guilty, until proven innocent !! "JN  2004
> 
> "Hardware eventually breaks - Software eventually works"  anon
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Why _TZ put times 7 minutes off?

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Edward Jaffe
> Sent: Friday, March 02, 2012 10:35 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Why _TZ put times 7 minutes off?
> 
> On 3/2/2012 8:25 PM, Joel C. Ewing wrote:
> > Particularly now that STP is just a matter of code rather than
> > hardware, it makes less and less sense (from the customer's viewpoint
> > of course) for this to be a chargeable feature, which was still the
> > case when I last checked.  As long as it is a chargeable feature it
> is
> > hard to cost-justify unless you are running a multi-system sysplex
> > environment that requires it or you have some unusual requirement
> that
> > really demands your TOD clock be that accurate.  That it is the "best
> > practice" and the only sure way for keeping the TOD clock accurate
> > makes it nice to have for a number of reasons; but if management asks
> > if it is a "must have" additional expense or a feature you can live
> without, in many cases the latter response must be given.
> 
> IMHO, STP should be included in the price of the machine.
> 

Agreed. The fact that syncing time cost money is one of the more egregious 
difficulties in explaining why mainframes are a good idea.

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

Re: Fwd: User datasets wrongly catalogued under Master Catalogue

[Gibney, Dave]

REPRO MERGECAT will certainly work, but Shane's also correct if the datasets 
aren't SMS.
Even if they are SMS, with proper authority, you could DELETE dsn NOSCRATCH and 
DEFINE RECATALOG 

If it was me, I'd use MERGECAT (I have that job  already in my library) unless 
it was a really large number of datasets, then since I have CR+, I'd use it.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Anthony Thompson
> Sent: Wednesday, February 29, 2012 12:11 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Fwd: User datasets wrongly catalogued under Master
> Catalogue
> 
> I think the reference is to REPRO MERGECAT... doubt that will help
> here.
> 
> Might be easiest to use DF/DSS to dump/delete datasets, then establish
> the proper catalogue alias, then RESTORE/catalogue the files. I imagine
> FDR can do the same thing.
> 
> I was looking at a piece of software here called T-Rex (by Dino-soft),
> but all it would help with is an INTEGRITYCHECK command to compare
> catalogues and verify the alias' are all correct and accounted for.
> 
> Ant.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Jake anderson
> Sent: Wednesday, 29 February 2012 5:25 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Fwd: User datasets wrongly catalogued under Master
> Catalogue
> 
> Robert,
> 
> I am unable to find any Information on MIGRATECAT on google search..
> 
> Is there someone who can point me to some Fine manuals relating to
> MIGRATCAT?
> 
> Jake
> 
> On Wed, Feb 29, 2012 at 1:04 PM, Vernooij, CP - SPLXM
>  > wrote:
> 
> > "Paul Gilmartin"  wrote in message
> > news:<5467422117818390.wa.paulgboulderaim@bama.ua.edu>...
> > > On Wed, 29 Feb 2012 09:14:36 +0530, Jake anderson wrote:
> > > >
> > > > typo - it happens when  a userid is *not* defined with alias
> > relating to
> > > >user catalog.
> > > >
> > > To my understanding, that's half right.  It happens when  a userid
> > > is
> > > *not* defined with alias relating to user catalog _and_ the master
> > > catalog is *not* suitably protected.
> > >
> > > I have a question on terminology:  someone stated here lately that
> > > user catalogs are ancient history; no longer used.  Is this so?  If
> > > so, how are user data sets catalogued?
> > >
> > > -- gil
> > >
> >
> > This was probably about CVOL catalogs, I remember this remark.
> >
> > Kees.
> >  
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only.
> > If you are not the addressee, you are notified that no part of the
> > e-mail or any attachment may be disclosed, copied or distributed, and
> > that any other action related to this e-mail or attachment is
> strictly
> > prohibited, and may be unlawful. If you have received this e-mail by
> > error, please notify the sender immediately by return e-mail, and
> delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> > its employees shall not be liable for the incorrect or incomplete
> > transmission of this e-mail or any attachments, nor responsible for
> any delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with
> > registered number 33014286
> > 
> >
> >
> > -
> -
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: User datasets wrongly catalogued under Master Catalogue

[Gibney, Dave]

You use IDCAMS to to a REPRO LEVEL(userid) MERGECAT from the master to the 
correct user catalog and then DEFINE the ALIAS.

There are Catalog enhancing utilities (Catalog Recovery Plus and the other one) 
that do this faster than IDCAMS if you have a large number of entries to move.
 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Jake anderson
> Sent: Tuesday, February 28, 2012 7:45 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Fwd: User datasets wrongly catalogued under Master Catalogue
> 
> "I agree that this happens when a userid is defined with alias relating to 
> user
> catalog."
> 
>  typo - it happens when  a userid is *not* defined with alias relating to user
> catalog.
> 
> -- Forwarded message --
> From: Jake anderson 
> Date: Wed, Feb 29, 2012 at 9:11 AM
> Subject: User datasets wrongly catalogued under Master Catalogue
> To: IBM Mainframe Discussion List 
> 
> 
> Hi,
> 
> Recently We have installed a new system Z/OS 1.13. During migration the
> Users datasets were restored and unfortunately all the user datasets are
> catalogued under Master catalogue. I agree that this happens when a userid
> is defined with alias relating to user catalog. I am just trying to 
> understand if it
> is possible to move all the users dataset catalogued under master catalogue
> to a user catalogue since the Number of datasets are in big number.
> 
> Jake
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: zSeries Manpower Sizing

[Gibney, Dave]

Isn't CICS via VTAM behind many ATMs :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Tony's Comcast account
> Sent: Friday, February 17, 2012 11:31 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: zSeries Manpower Sizing
> 
> Wow, imagine running a PCI application on USS.  ;-)
> 

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

Re: zSeries Manpower Sizing

[Gibney, Dave]

Well, I can say that one is not really enough, but some of us try. 
I think I could keep z/OS current, plus a few other ISV products, if there 
wasn't day to day needs and the occasional urgent demand for special requests.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of George Henke
> Sent: Thursday, February 16, 2012 1:19 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: zSeries Manpower Sizing
> 
> I am trying to find out how much staff, numbers and titles, eg z/OS, z/VM,
> VTAM/TCPIP, CICS, etc, are needed to run a large zSeries mainframe shop.
> 
> Would some of you be so kind as to share that information with me.
> 
> 
> --
> George Henke
> (C) 845 401 5614
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Gibney, Dave]

  Pretty much the latter, with release at YI for most. EXTENDED as the default. 
I have a DATACLAS=BIG vs. BIGEXT to use for the few cases that can't be 
extended. Haven't seen an x37 in ages (except for some truly large SMF/PDB 
files) where the required space needs a bit of hand holding. It does take 
generous pools and a somewhat aggressive DFHSM migration policy with low 
thresholds. 
> >
> >   But, this is precisely what SMS and DATACLAS are for. It does
> > accomplish, for the most part, SPACE=ANY.
> > Not fully using SMS is so 80s'
> 
> If so, do You really see everyone that creates and submits JCLs to
> create/change DATACLAS/STORCLAS instead of editing the SPACE= parms ?
> Or do You envision DATACLAS/STORCLAS's with very generous SPACE
> allocations (for every allocation) ?
> 
> 
> 
> Regards,
> Thomas Berg
> _
> Thomas Berg   Specialist   A M   SWEDBANK
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Gibney, Dave]

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Thomas Berg
> Sent: Monday, February 13, 2012 5:11 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: SV: Archaic allocation in JCL (Was: Physical record size query)
> 
> > -Ursprungligt meddelande-
> > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
> > Lizette Koehler
> > Skickat: den 13 februari 2012 12:43
> > Till: IBM-MAIN@bama.ua.edu
> > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query)
> >
> > >
> > > I can't understand why we STILL need to specify SPACE= (etc) for an
> > allocation of a
> > > dataset.
> > > You normally don't do that in other OS (platforms), You always (both
> > principally and in
> > > practice) want to allocate as much as is needed during execution
> > >
> > > If for backward compatibility it can't be done automatically, why not
> > introduce a new
> > > keyword like e g "SPACE=ANY" ?
> > >
> > >
> >
> > Thomas,
> >
> > IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the
> > Space requirements there.  Then the JCL does not require Space.  Have you
> > looked at that?  However, then that makes your storage admin responsible
> > for
> > ensuring the space is enough.  And if needed alter the dataclass if there
> > are space issues.  And it would require all such datasets be SMS managed.
> >
> >
> > Lizette
> 
> Hi Lizette,
> 
> In practice it's not a viable alternative. Besides the need (if doing it that 
> way)
> to communicate frequently with the "space gang", it's to many variants of
> datasetnames and to many different needs for space depending on time,
> date and subgrouping within applications.
> 


  But, this is precisely what SMS and DATACLAS are for. It does accomplish, for 
the most part, SPACE=ANY.
Not fully using SMS is so 80s'

Dave Gibney
Information Technology Services
Washington State University

> 
> 
> Regards,
> Thomas Berg
> _
> Thomas Berg   Specialist   A M   SWEDBANK
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: WLM Capping

[Gibney, Dave]

We had been sending SCRT reports for quite a while before we capped. I had 
never seen it above about 22 or 24, can't remember. I started there and backed 
it down by one a month until nightly batch was having trouble completing before 
the next day and then went back up on or two. We landed at 16 and haven't had 
troubles since. 

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of David Andrews
> Sent: Tuesday, February 07, 2012 1:31 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WLM Capping
> 
> On Tue, 2012-02-07 at 15:51 -0500, Gibney, Dave wrote:
> > I don't want to imagine what WLM stomping on the brakes looks like in
> > your shop.
> 
> Biggest hassle for me when I started softcapping was that most of my
> batch had been discretionary - I always liked the MTTW algorithm.  But
> when we softcapped all that discretionary workload went to the meat
> locker, and we couldn't have that.  Had to do some triage and creative
> stuff with velocity goals and performance periods to make things right
> again.
> 
> --
> David Andrews
> A. Duda & Sons, Inc.
> david.andr...@duda.com

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

Re: WLM Capping

[Gibney, Dave]

We had been sending SCRT reports for quite a while before we capped. I had 
never seen it above about 22 or 24, can't remember. I started there and backed 
it down by one a month until nightly batch was having trouble completing before 
the next day and then went back up on or two. We landed at 16 and haven't had 
troubles since. 

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of David Andrews
> Sent: Tuesday, February 07, 2012 1:31 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WLM Capping
> 
> On Tue, 2012-02-07 at 15:51 -0500, Gibney, Dave wrote:
> > I don't want to imagine what WLM stomping on the brakes looks like in
> > your shop.
> 
> Biggest hassle for me when I started softcapping was that most of my
> batch had been discretionary - I always liked the MTTW algorithm.  But
> when we softcapped all that discretionary workload went to the meat
> locker, and we couldn't have that.  Had to do some triage and creative
> stuff with velocity goals and performance periods to make things right
> again.
> 
> --
> David Andrews
> A. Duda & Sons, Inc.
> david.andr...@duda.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: WLM Capping

[Gibney, Dave]

Thanks Bob for the sample code. I didn't realize how back level I am on MXG :(
MXG 22.09 DATED AUG 25, 2004 HAS BEEN SUCCESSFULLY INITIALIZED.

Like I said, other fish of higher priority. Still SAS 8.1 also.

Brad, fortunately, my z9-L03 has three processors, so the pain of capping is 
only really felt in the development and testing LPARs. I did my time on a uni 
and I will strongly resist ever going back. I don't want to imagine what WLM 
stomping on the brakes looks like in your shop.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Wissink, Brad [ITSYS]
> Sent: Tuesday, February 07, 2012 12:28 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WLM Capping
> 
> I don't know about SMF and capping, but when our processor is capped we
> know about it big time.  We have a z/10 P01 Uniprocessor and when capping
> kicks in it cuts our CPU busy in half and things come to a standstill.   We 
> use
> RMF III CPC reports to watch how close we are getting to being capped.  We
> found some documentation on how to build a RMF III User report which has
> 'Time Until Capping'.   We usually know capping is getting close because we
> have been running the processor close to or at 100% busy for some length of
> time before capping kicks in.
> 
> Brad Wissink
> Information Technology Services
> Iowa State University
> 515-294-3088
> 
> -Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Gibney, Dave
> Sent: Tuesday, February 07, 2012 2:01 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: WLM Capping
> 
>   I apologize for asking what is likely a basic performance question. It's 
> been
> about four years since we went from underpowered to having plenty and I
> was frying other fish.
>   How can I determine from SMF when we were being capped by WLM. I
> have the cap set at 16 MSU. We are preparing to run some large conversions
> and the money people want some assurance that lifting the cap will help
> enough to justify the expense.
>   I have MXG and still run the daily PDB stuff. I just haven't needed to look 
> at
> it for some time.
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

WLM Capping

[Gibney, Dave]

  I apologize for asking what is likely a basic performance question. It's been 
about four years since we went from underpowered to having plenty and I was 
frying other fish.
  How can I determine from SMF when we were being capped by WLM. I have the cap 
set at 16 MSU. We are preparing to run some large conversions and the money 
people want some assurance that lifting the cap will help enough to justify the 
expense.
  I have MXG and still run the daily PDB stuff. I just haven't needed to look 
at it for some time.

Dave Gibney
Information Technology Services
Washington State University

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

Re: PDSE

[Gibney, Dave]

In theory and with proper planning, one should not need to compress active 
linklisted libraries, PDS or PDSE.
After all, you should not be updating your live system datasets. Maintenance 
should be done on copies and brought in via (rolling) IPL.

The idea of application libraries in the linklist is not something I like, but 
they can certainly be dynamically added after IPL and removed, update/compress, 
re-added for maintenance. Even here, a copy with decent change control is a 
better idea.

After saying this, I do have a couple libraries where this need arises. But, 
with them, I do know which address spaces are using them and I am not risking 
full system outage if I cheat.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Scott Ford
> Sent: Friday, January 20, 2012 12:46 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PDSE
> 
> So this has my curiosity peaked, how does IBM suggest doing a compress on
> a Linklist lib that needs compressing, inquiring minds would love to know ?
> 
> Sent from my iPad
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> 
> 
> On Jan 20, 2012, at 8:09 AM, Peter Relson  wrote:
> 
> >> Try running an IEBCopy compress against the data set (option "z" against.
> >
> >> TSO-ISPF display of the PDSE). It might be a little complicated as it's
> >> in the Linklist, and so disp=old wouldn't work (still allocated to LLA),
> >> so you'll have to use disp=shri in a batch job.
> >
> > This is not good advice, in general. Of course it's your system, so
> > shooting yourself in the foot is always an option you are allowed to take.
> >
> > The system allocates LNKLST data sets for a reason -- so that you can't
> > get the data set DISP=OLD which in turn means that if you're doing things
> > right you will not be able to do such damaging operations as compress
> > (where for compress "doing things right" means getting the data set
> > DISP=OLD, and by "damaging" I mean damaging to other processes that
> might
> > have knowledge of where a member is within the data set, not damaging
> to
> > the data set itself).
> >
> > Bluntly, if you compress a LNKLST data set without DISP=OLD, then don't
> > complain if something related to that data set no longer works.
> >
> > If you must compress the data set, then get it out of the LNKLST and out
> > of LLA management. And note that there is no fully safe way to do the
> > former unless you have added the data set to the now-activated LNKLST
> set
> > after IPL and are able to terminate/restart all jobs that started after
> > that LNKLST set was activated.
> >
> > Should compress require DISP=OLD? Maybe. But that's unlikely to change,
> > and definitely won't change as a system default (one could imagine giving
> > the customer a knob to ask that for their system the default be that).
> >
> > Peter Relson
> > z/OS Core Technology Design
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Clarification on Sysres Volumes(RMF)

[Gibney, Dave]

Dave Gibney
Information Technology Services
Washington State University

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, January 03, 2012 5:47 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Clarification on Sysres Volumes(RMF)
> 
> >
> > Hi Lizette,
> >
> > Apology for not being precise.
> >
> > Datasets found in SYSRES are :
> >
> > are some BCP related datasets , assembler datasets,language environment
> > datasets,IBM book manager datasets First failure Support technology(FFST)
> datasets
> > are found.
> >
> > During This Situation when I do : /D GRS,C  It does really produces any
> information
> > about Volume or Dataset Contention. As per Mark advise I did TSO
> RMFMON
> and Found
> > some SYS1.HASCKPT datasets used by JES2, some User Job using their
> Assigned
> > volumes.
> >
> > Jags
> >
> 
> Jags,
> 
> It is important to provide information when asked.  We cannot see your
> environment.  When you ask a question - How can I fix this.  We must ask
> questions to help.
> 
> The areas you need to research are
> 
> 1)  GRS entries.  Is your GRSRNLxx member setup correctly for your
> environment.
> 2)  Verify what files are accessed when this occurs
> 3)  Verify you only have z/OS TLIB datasets on your SYSRES volume.  If you
> have other datasets, you need to determine the impact to your SYSRES
> volume.
> 4)  Verify if you have any HFS or zFS files on your SYSRES volume.
> 5)  Verify if you have any SYS1.DUMPxx datasets on your SYSRES volume
> 6)  Verify if you have any Security (RACF, Top Secret, ACF2) Data bases on
> your SYSRES volume
> 7)  Run performance reports on your volume to see what is open during the
> time of RMF issue.  Identify what datasets have the highest access during
> the RMF issue.
> 

I would add "and move elsewhere" after the word "Verify" in the above advice. :)

Dave Gibney
Information Technology Services
Washington State University


> Are you saying you have the JES2 HASPCKPT dataset on your SYSRES
> Volume?
> That needs to move.  It should be on a separate volume.
> 
> You must do these steps.  You must review your system.  You will need to do
> the analysis to determine your issue.
> 
> When starting to understand I/O issues with volumes, this is a good overview
> http://publib.boulder.ibm.com/tividd/td/TDS390/SH19-6818-
> 08/en_US/HTML/DRLM9
> mst61.htm
> 
> 
> And the following REDBOOKs should help
> 
> Effective zSeries Performance Monitoring Using Resource Measurement
> Facility
> http://www.redbooks.ibm.com/abstracts/sg246645.html?Open
> 
> Using Resource Measurement Facility Monitor III Efficiently
> http://www.redbooks.ibm.com/abstracts/gg244131.html?Open
> 
> Parallel Sysplex Performance Healthcheck Case Study: DMData/Danske Data
> http://www.redbooks.ibm.com/abstracts/sg245373.html?Open
> 
> 
> The only datasets on a SYSRES IMHO are the Tlibs from the serverpac/cpac or
> initial install.  All other datasets should be on a separate volume(s).
> 
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: JCL "sheesh!" for today

[Gibney, Dave]

Actually, even attempting to access the link provided here was unhelpful.

I really don't care. Sometime your messages contain useful enough info to 
continue to read them long enough to hit the delete :) I would guess as much as 
20% of time, there is enough context and your reply is timely.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Monday, December 12, 2011 8:14 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL "sheesh!" for today
> 
> In <0de6a9840123e547b061ac5b6765c026240...@exmb-05.ad.wsu.edu>,
> on    
> 12/12/2011
>at 08:55 AM, "Gibney, Dave"  said:
> 
> >Actually, often it is difficult to know what you are replying to and
> >the "attribution" requires extra clicks, windows and effort.
> 
> No.
> 
> >If fact, until this latest exchange, I had not previously noticed
> >these links in your replies.
> 
> Then it obviously didn't require extra clicks, etc.
> 
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
> 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...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is there an IBM program that will tell me what job created a DASD DSN?

[Gibney, Dave]

Actually, IBM does supply DFSORT which makes the answer to the question yes 
plus SMOP. For some complex value of simple :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Lizette Koehler
> Sent: Monday, December 12, 2011 1:33 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Is there an IBM program that will tell me what job created a
> DASD DSN?
> 
> >
> > Liz,
> >
> >The list you provided is OK, but in reality you really only need DAF and its
> free.
> >While the others an do the job well I might add. The simple answer is
> usually the best.
> >
> >Ed
> >
> 
> 
> Absolutely agree.  DAF is usually sufficient.
> 
> However, some shops do not like "freeware" and this shop may already have
> SAS+MICS or SAS+MXG to do this and may not allow the use of DAF.
> 
> So a more general list - do to the lack of information about this shop.
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL "sheesh!" for today

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Sunday, December 11, 2011 2:20 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL "sheesh!" for today
> 
> In <9480536010373504.wa.paulgboulderaim@bama.ua.edu>, on
> 12/11/2011
>at 12:00 PM, Paul Gilmartin  said:
> 
> >At least one word.  Sometimes several.
> 
> Always enough to identify the text that I an responding to. If I'm
> responding to an entire paragraph then I quote the entire paragraph,
> but I don't quote extraneous text as some here do.
> 

Actually, often it is difficult to know what you are replying to and the 
"attribution" requires extra clicks, windows and effort.
If fact, until this latest exchange, I had not previously noticed these links 
in your replies.


> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> 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...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Difference between IEF458D and IEF099I

[Gibney, Dave]

You are correct. My mistake :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Ford Prefect
> Sent: Saturday, December 03, 2011 1:26 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Difference between IEF458D and IEF099I
> 
> Dave,
> 
> This thread isn't about unit allocation, it's about dataset contention.
> Replying no in this case will cause a failure of dynamic allocation.
> 
> On Fri, Dec 2, 2011 at 7:48 PM, Gibney, Dave  wrote:
> 
> > One of the first automations we put in oh so many moons ago :), was
> to
> > always reply no and then nohold to this situation. Back then, it was
> > always not enough tape drives that caused it. Now, we have no tapes
> > for general use (I implemented "TMM" and divert all to disk) and once
> > in a long while, this triggers without ill effect.
> >
> > Dave Gibney
> > Information Technology Services
> > Washington State University
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu]
> On
> > > Behalf Of Lizette Koehler
> > > Sent: Friday, December 02, 2011 8:19 AM
> > > To: IBM-MAIN@bama.ua.edu
> > > Subject: Re: Difference between IEF458D and IEF099I
> > >
> > > >
> > > >>z/OS V1.11
> > > >>
> > > >>We get many jobs contending for datasets.  These are all DASD
> > > >>rather
> > than
> > > tape.
> > > >>
> > > >>Sometimes I will see the IEF458D message and sometimes the
> IEF099I.
> > > >
> > > >
> > > >IEF458D jobname stepname WAITING FOR DATASET. TO CANCEL WAIT
> > > REPLY 'NO'
> > > >
> > > >Explanation:  For authorized dynamic allocation, the system
> > > >requires a data set that is in use by another job. Message IEF863I
> > > >names the data set.
> > > >
> > > >
> > > >
> > > >IEF099I JOB jobname WAITING FOR DATA SETS
> > > >
> > > >Explanation:  During initialization of a job, the job required
> data
> > > >sets that were not available. These data sets are named in message
> IEF863I.
> > > >When the data sets become available, the system will reserve them
> > > >for
> > the
> > > >job and job initialization will continue.
> > > >
> > > >
> > > >>I am trying to see what the difference is which causes one of
> > > >>these
> > two to
> > > be produced.
> > > >
> > > >It looks like you get IEF099I when the data set is in the JCL and
> > IEF485D
> > > >when it is requested by dynamic allocation.
> > > >
> > > >>And how I can get the IEF458D to not show up.
> > > >
> > > >Be careful what you wish for. If indeed IEF458D is for dynamic
> > allocation,
> > > >the message allows you to cancel to avoid a deadlock.
> > > >
> > > >>I do have OPS/MVS so a complete suppression would work, but if it
> > > >>were
> > > TAPE I think I need to see it.
> > > >
> > > >Do you have jobs that dynamically allocate tape data sets?
> > > >
> > > >--
> > > >Tom Marchant
> > > >
> > >
> > > Yes - Through the Change Control Process used by CA-Endevor.  I
> > > would
> > also
> > > suspect that Changeman might also do this.
> > >
> > > Lizette
> > >
> > > ---
> -
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> > > INFO Search the archives at
> > > http://bama.ua.edu/archives/ibm-main.html
> >
> > -
> -
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Difference between IEF458D and IEF099I

[Gibney, Dave]

One of the first automations we put in oh so many moons ago :), was to always 
reply no and then nohold to this situation. Back then, it was always not enough 
tape drives that caused it. Now, we have no tapes for general use (I 
implemented "TMM" and divert all to disk) and once in a long while, this 
triggers without ill effect.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Lizette Koehler
> Sent: Friday, December 02, 2011 8:19 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Difference between IEF458D and IEF099I
> 
> >
> >>z/OS V1.11
> >>
> >>We get many jobs contending for datasets.  These are all DASD rather than
> tape.
> >>
> >>Sometimes I will see the IEF458D message and sometimes the IEF099I.
> >
> >
> >IEF458D jobname stepname WAITING FOR DATASET. TO CANCEL WAIT
> REPLY 'NO'
> >
> >Explanation:  For authorized dynamic allocation, the system requires a
> >data set that is in use by another job. Message IEF863I names the data
> >set.
> >
> >
> >
> >IEF099I JOB jobname WAITING FOR DATA SETS
> >
> >Explanation:  During initialization of a job, the job required data sets
> >that were not available. These data sets are named in message IEF863I.
> >When the data sets become available, the system will reserve them for the
> >job and job initialization will continue.
> >
> >
> >>I am trying to see what the difference is which causes one of these two to
> be produced.
> >
> >It looks like you get IEF099I when the data set is in the JCL and IEF485D
> >when it is requested by dynamic allocation.
> >
> >>And how I can get the IEF458D to not show up.
> >
> >Be careful what you wish for. If indeed IEF458D is for dynamic allocation,
> >the message allows you to cancel to avoid a deadlock.
> >
> >>I do have OPS/MVS so a complete suppression would work, but if it were
> TAPE I think I need to see it.
> >
> >Do you have jobs that dynamically allocate tape data sets?
> >
> >--
> >Tom Marchant
> >
> 
> Yes - Through the Change Control Process used by CA-Endevor.  I would also
> suspect that Changeman might also do this.
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TIBCO ES start up error - Duplicate ID

[Gibney, Dave]

Knowing nothing at all about what TIBCO may be, I would guess a syntax error in 
TIBCO.CNTL(SXSSSP$1). A duplicated parameter perhaps. I would also expect more 
info from one or more of the SYSOUT's TIBLPARM for example. Then I'd look 
SXS2019E up in the products message manual (if you have an install manual, I 
would hope you have a msg manual). I would expect rc=8 rsn=261 to be fairly 
specific.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of jagadishan perumal
> Sent: Wednesday, November 30, 2011 8:57 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: TIBCO ES start up error - Duplicate ID
> 
> Hi,
> 
> Recently I tried installing TIBCO ES, after all the consecutive steps
> the final step was to start the TIBCO ES server. The TIBCO start up
> ended with the below error :
> 
> Start Up proc :
> 
> //SXSESSS JOB (&SYSUID),'SUBSTATION ES START',
> // CLASS=A,
> // TIME=1440,
> // REGION=0M,
> // NOTIFY=&SYSUID,
> // MSGCLASS=X,
> // MSGLEVEL=(1,1)
> //*
> /*JOBPARM BYTES=99,CARDS=99,LINES=,PAGES=9
> //*
> //
> //*
> //* EXECUTE THE TIBCO SUBSTATION ES
> //* ---
> //*
> //* Instructions:
> //*   Issue CAPS OFF when modifying this file.
> //*   Refer to the Tibco Substation Installation manual for the
> //* System Startup paramaters (SSP) defintions and usage
> //*
> //*
> //*   ===
> //*
> //*   TIBCO Substation(tm) ES for z/OS
> //*
> //*   Copyright (c) 1994-2010 Tibco Software Inc.
> //*   Tibco technology is protected under these US patent numbers:
> //* 5187787; 5257369; 5557798.
> //*   All rights reserved.
> //*
> //*
> //
> //*
> //*   GLOBALS:
> //*
> //  SET USERHLQ=TIBCO
> //  SET CICSHLQ=CICSTS31.CICS
> //*
> //*
> //TIBSSMT  EXEC PGM=TIBSSMT2,REGION=0M,
> // PARM='-SSPMEM SXSSSP$1'
> //*
> //* Libraries in this concatenation must be Authorized //STEPLIB  DD
> DISP=SHR,DSN=&USERHLQ..AUTH
> // DD DISP=SHR,DSN=&CICSHLQ..SDFHEXCI
> //*
> //SYSLIB   DD DISP=SHR,DSN=CEE.SCEERUN
> //*
> //**  TIBCO Substation ES - Control files
> //*
> //TIBPARM  DD DISP=SHR,DSN=&USERHLQ..CNTL
> //TIBCFG   DD DISP=SHR,DSN=&USERHLQ..CFGIVP
> //*
> //**  Parameter Audit output (v1.1)
> //*
> //TIBLPARM DD SYSOUT=*
> //*
> //*
> //**  TIBCO Substation ES - Log and Trace Files
> //*
> //TIBLOGPR DD SYSOUT=*
> //TIBTRCPR DD SYSOUT=*
> //*
> //**  TIBCO Substation ES - Log and Trace Debug Files
> //*
> //TIBLOGDB DD SYSOUT=*
> //TIBTRCDB DD SYSOUT=*
> //*
> //**  Used for Disk Logging and Tracing (v1.1)
> //**  Initially not setup to be used
> //*
> //*TIBLOGF1 DD DISP=SHR,DSN=&USERHLQ..LOG.DISKF1
> //*TIBLOGF2 DD DISP=SHR,DSN=&USERHLQ..LOG.DISKF2
> //*TIBTRCF1 DD DISP=SHR,DSN=&USERHLQ..TRC.DISKF1
> //*TIBTRCF2 DD DISP=SHR,DSN=&USERHLQ..TRC.DISKF2
> //*
> //**  SSL Certificate Files
> //*
> //*SSLCCERT DD DISP=SHR,DSN=&USERHLQ..CNTL(SSLCCERT)
> //*SSLCKEY  DD DISP=SHR,DSN=&USERHLQ..CNTL(SSLCKEY)
> //*
> //*
> //**  System miscellaneous definitions
> //*
> //SYSMDUMP DD SYSOUT=*
> //SYSPRINT DD SYSOUT=*
> //SYSOUT   DD SYSOUT=*
> //STDOUT   DD SYSOUT=*
> //STDERR   DD SYSOUT=*
> //CEEOUT   DD SYSOUT=*
> //CEEDUMP  DD SYSOUT=*
> //TIBLEMSG DD SYSOUT=*
> //TIBUOESB DD SYSOUT=*
> //TIBUOMSG DD SYSOUT=*
> //TIBUOSXC DD SYSOUT=*
> //* Use ONLY when needed. This would affect performance //*CEEOPTS  DD
> *
> //*RPTSTG(ON)
> 
> 
> Error message :
> 
>Now logging for date
> 2011/12/01
> 09:03:07.7317 SXG1600I Log Agent Starting - Logging to TIBLOGPR
> 09:03:07.7447 SXG1800I Parameter Log Agent Starting - Logging to
> TIBLPARM
> 09:03:07.7717 SXG1700I Trace Agent Starting - Tracing to TIBTRCPR
> 09:03:07.7738 SXS1000I Starting ~ TIBCO Substation (ES) for z/OS
> 09:03:07.7748 SXS1009I Substation (ES) - Version
> 2.6.0.0
> *09:03:07.8889 SXS2019E Found Duplicate IId:   ESB01 RC:8 RSN:261*
> - >
> duplication found
> 09:03:07.8889 SXG2803W Terminating ~ Substation ES for IVP's
> 09:03:08.8899 SXG1801I Parameter Log
> closed
> 09:03:08.8947 SXG1701I Trace Agent
> terminating
> 09:03:08.8998 SXG1601I Log Agent terminating & file closed
> 
> Please share your expertise tips if you had similar experience during
> TIBCO start up. I tried Googling but Not able to trace the cause for
> this error message.
> 
> Jags
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: RSU Unzip

[Gibney, Dave]

There is a DDDEF defined for SYSUT1 in your SMP/E set-up. Make the allocation 
much bigger.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of saurabh khandelwal
> Sent: Friday, November 25, 2011 7:35 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: RSU Unzip
> 
> Hello,
> I am not using SYSUT1 in my unzip program. I am just using SYSUT3 and
> SYSUT4. Then I am not able to understand, why we are getting error for
> SYSUT1
> 
> Do I have to code SYSUT1 in my UNZIP program?
> 
> //UNZIPRSU JOB (3623),'SAURABH',MSGCLASS=X, CLASS=A,
> // NOTIFY=&SYSUID,REGION=0M
> //UNZIPEXEC PGM=GIMUNZIP,PARM='HASH=NO'
> //SYSUT3   DD UNIT=3390,SPACE=(CYL,(400,100))
> //SYSUT4   DD UNIT=3390,SPACE=(CYL,(400,100))
> //SMPOUT   DD SYSOUT=*
> //SYSPRINT DD SYSOUT=*
> //SMPDIR   DD PATH='/u/zos111/rsu1110',
> //PATHDISP=KEEP
> //SYSINDD DATA,DLM=$$
> 
>  name="SMPPTFIN/S0001.SHOPZ.S5586833.SMPMCS.pax.Z"
> volume="*(RSU006,RSU007)*"
> newname="SMPE.ZOS111.RSU.S5586833.SMPMCS">
> 
>  name="SMPHOLD/S0002.SHOPZ.S5586833.SMPHOLD.pax.Z"
> volume="RSU006"
> newname="SMPE.ZOS111.RSU.S5586833.SMPHOLD">
> 
> 
> $$
> 
> Regards
> Saurabh
> 
> On Sat, Nov 26, 2011 at 12:10 AM, Lizette Koehler
> wrote:
> 
> > >  I am trying to unzip the RSU, which I have received in USS
> > > at /u/zos111/rsu1110. I am using below JCL for unzip. But I am
> > > getting
> > B37-04
> > RC code,
> > > while running this.
> > >
> > > IRR010I  USERID TEC1008  IS ASSIGNED TO THIS JOB.
> > > ICH70001I TEC1008  LAST ACCESS AT 08:46:22 ON FRIDAY, NOVEMBE
> > > $HASP373 UNZIPRSU STARTED - INIT 1- CLASS A - SYS SYE1
> > > IKJ56232I DATA SET SMPE.ZOS111.RSU.S5586833.SMPMCS NOT ON VOL
> > > IKJ56228I DATA SET SMPE.ZOS111.RSU.S5586833.SMPMCS NOT IN CAT
> > > IEC030I B37-
> > > 04,IFG0554A,UNZIPRSU,UNZIP,SYSUT1,56D6,RSU006,042
> > > IEA995I SYMPTOM DUMP OUTPUT  806
> > > SYSTEM COMPLETION CODE=B37  REASON CODE=0004
> >
> >
> > In your SMPE Zone, increase the size for SYSUT1 or hardcode the SYSUT1
> > with LOTS of SPACE
> >
> > 04,IFG0554A,UNZIPRSU,UNZIP,SYSUT1,56D6,RSU006,042
> >
> >
> > Also, this link may have information
> >
> >
> > http://newsgroups.derkeiler.com/Archive/Comp/bit.listserv.ibm-main/200
> > 8-05/m
> > sg01496.html
> >
> >
> > IF the unzip is for a PDSE dataset, then you might need maintenance.
> >
> >
> > 15. 10/04/08 Users Affected:
> > All z/OS SystemPac customers who want to restore
> > their electronic order archives.
> > .
> > Problem Description:
> > While running the RESTORE or GETORDER job it
> > encounters a SB37 abend for SYSUT1 for a
> > temporary data set in steps which execute
> > GIMUNZIP program.
> > .
> > Action Required:
> > Apply corrective maintenance as required by APARs
> > IO07810 and IO10377.
> >
> > Lizette
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> 
> 
> 
> --
> Thanks & Regards
> Saurabh Khandelwal
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
> archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ABEND S0C4 REASON CODE=0011

[Gibney, Dave]

LISTGRP * group be quite large, try LISTGRP a* and b* etc. and see if that 
helps.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of HELIO
> Sent: Friday, November 25, 2011 11:54 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: ABEND S0C4 REASON CODE=0011
> 
> YES, I HAVE RUN WITH REGION = 0M
> 
> 
> 
> Em 25/11/2011 17:23, Sambataro, Anthony (NIH/NBS) [E] escreveu:
> > Have you tried REGION=0M?
> >
> > -Original Message-
> > From: HELIO [mailto:helio.si...@rural.com.br]
> > Sent: Friday, November 25, 2011 2:02 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Fwd: ABEND S0C4 REASON CODE=0011
> >
> > All list,
> >
> > I run a job with the IKJEFT01 program and REGION=8M,but it abended ans
> > display following info.
> >
> > IEA995I SYMPTOM DUMP OUTPUT169
> >
> > SYSTEM COMPLETION CODE=0C4REASON CODE=0011
> >
> > TIME=15.45.46SEQ=01531CPU=ASID=0043
> >
> > PSW AT TIME OF ERROR078D2005DBB8ILC 6INTC 11
> >
> > ACTIVE LOAD MODULEADDRESS=0005C7C8OFFSET=13F0
> >
> > NAME=ICHCLG00
> >
> > DATA AT PSW0005DBB2 - 601E58E0BA75D202BD11E002
> >
> > GR 0: _00011: _0005ED28
> >
> > 2: _0005BA083: _0005F5E2
> >
> > 4: _0006D0005: _
> >
> > 6: _0006EC407: _00073FF3
> >
> > 8: _00073FF69: _0006EC7D
> >
> > A: _0005F36EB: _0005E36F
> >
> > C: _0005D370D: _0005EC4C
> >
> > E: _00073FFCF: 0004_
> >
> > END OF SYMPTOM DUMP
> >
> > This my job
> >
> > //RACFGROU JOBF0,'SUPPORT',CLASS=6,TIME=(0004,00),
> >
> > //MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=&SYSUID
> >
> > //*
> >
> > //CE1E001 EXEC PGM=IKJEFT01,REGION=8M
> >
> > //SYSTSPRT DDDISP=(NEW,CATLG,CATLG),
> >
> > //DSN=RWA0001.RACF.LIST.GROUPS,
> >
> > //SPACE=(TRK,(5000,500),RLSE),UNIT=SYSALLDA,
> >
> > //RECFM=VBA,LRECL=137,BLKSIZE=0
> >
> > //SYSTSINDD *
> >
> > PROFILE NOPREFIX
> >
> > LISTGRP *
> >
> > LOGOFF
> >
> > /*
> >
> > Could anybody help me check the error ?
> >
> > By the way, I run it in different region of the job/step, 64M, 0M, but
> > it's keep abended.
> >
> > Thanks.
> >
> > Hélio José
> >
> > 
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> >
> 
> 
> --
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
> archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SDSF versus (E)JES

[Gibney, Dave]

We did several years ago. Phoenix support is excellent, the install almost 
trivial. 

It did take an extra IPL of my last serverpac to get (E)JES available :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Ivanno Alexander
> Sent: Sunday, November 20, 2011 4:18 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: SDSF versus (E)JES
> 
> Hello.
> 
> Does any of you guys use (E)JES and dropped the IBM payment of SDSF?
> 
> Regards,
> 
> Ivan
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
> archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Clarification on IEHPROGM

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Matthew Stitt
> Sent: Tuesday, November 15, 2011 1:07 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Clarification on IEHPROGM
> 
> The only use I have for IEHPROGM is to delete the temporary datasets which
> remain on the PUBLIC and STORAGE volumes for various reasons.  That
> function still works quite well.

So does not having PUBLIC and STORAGE volumes :) 
The first step in the example SMS conversion is managing temp datasets.

I not only agree with Rick in being unable to imagine a reason to use IEHPROGM, 
I would actively discourage anyone here who wanted to use it. 

Dave Gibney
Information Technology Services
Washington State University

> 
> I believe the OPs original questions was why it returned a message indicating
> a security problem, I.E. incorrect password, not an indication that the new
> name desired was already in existence.  The fact the dataset is SMS managed
> probably is what led to the error message he got.  According to the
> documentation presented earlier, this likely means the error message
> wording should be changed.
> 
> But then again, IEHPROGM could be in the category of "functionally
> stabilized".
> 
> ---
> I am trying RENAME for NON-VSAM, but I used your Given JCL to rename
> with existing name itself but it conflicts with Duplicate
> name(Obviously) Since the NEWNAME do already do exist.
> 
> But my clarification why IEHPROGM throws an error as "Correct Password
> not available" whereas we have not protected the Dataset with Password ?
> -
> Jake, since IEHPROGM was written, some of the bits in the Format-1 DSCB
> have been "re-purposed" after becoming archaic. This can, and often
> will, become VERY confusing when using old programs with new control
> blocks. Not just in this situation, either. The example you're hitting
> is the use of the PASSWORD bits in the Format-1 DSCB.
> 
> I, personally, can think of no good reason to ever use IEHPROGM in a
> z/OS environment; IDCAMS is the "current" vehicle for the kinds of
> changes that IEHPROGM once performed admirably well.
> 
> Rick
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: C newbie - pass a LDAP handle out to calling routine

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Bill Godfrey
> Sent: Sunday, November 06, 2011 7:53 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: C newbie - pass a LDAP handle out to calling routine
> 
> On Fri, 4 Nov 2011 21:39:43 +, Dave Gibney wrote:
> 
> >  This is my first experience with C, but a language is a language
> after the 3rd or 4th :)
> >I'm calling C for LDAP queries from Natural (Software AG "4"GL) in
> batch. And it works, sort of.
> >One FM is IBM Tivoli Directory Server Client Programming for z/OS
> >
> >  If I use the sequence ldap_init, ldap_simple_bind_s, ldap_search,
> ldap_unbind, it gets overloaded after 5 calls at the speed of batch. If
> I leave out the unbind, it works for thousands of calls, but there is
> an obvious memory leak.
> >  So, I want to anchor the ldap handle in the main driving program. I
> made a simple C stub:
> >
> >extern int ret2nat (int  *back_value, LDAP *ld, char *msg)
> >#include 
> >
> >In ldap.h there is:
> >typedef struct ldap LDAP;
> >
> >The examples use:
> >LDAP * ld;
> >To declare an ldap_handle which according to the listing is an:
> >ld  6270-1:1931 Class = parameter, Length = 4
> >Type = pointer to incomplete
> struct ldap
> >
> >I have a function:
> >LDAP * bind_adlds(char *hostname, char *container, char *msg)
> >And I call it:
> >printf("ld before bind   :%d\n",ld);   /* ld before bind
> :286352012
> >ld = bind_adlds(hostname, container, msg) ;
> >printf("ld after bind:%d\n",ld);/* ld after bind
> :283317144
> >
> >but the value is not returned to the caller of ret2nat.
> >
> >Any attempts to use *ld in an assignment or even memcpy() get a
> complier message:
> >ERROR CCN3285 /u/ldap/test.c:46The indirection operator cannot be
> applied to a pointer to an incomplete struct or union.
> >Or
> >WARNING CCN3068 /u/ldap/test.c:46Operation between types "int*"
> and "pointer to an incomplete type" is not allowed.
> >
> >As I said, I am just learning how to spell C. I know I am fighting
> some kind of battle of types. I welcome even derisive comments, if in
> the end thay help.
> >
> >Dave Gibney
> >Information Technology Services
> >Washington State University
> >
> 
> I'm not sure I understand the design of your program. You seem to have
> a "main driver" program, and an int function named "ret2nat" which
> accepts an LDAP * as one of its arguments, and a "bind_adlds" function
> which sets the value of an LDAP *. But I don't follow how the sequence
> of function calls are supposed to work. Maybe what I have to say will
> cause you to redo the design.
> 
> What you call a "stub" might be the first statement in a function, or a
> function prototype without the trailing semicolon, I'm not sure which.
> I don't think the "extern" is needed for functions.
> 
> This statement, which I presume is in your "main driver" program,
> LDAP * ld;
> defines a pointer to an LDAP structure, but initially it does not point
> to anything. It does not put an LDAP structure in your main program.
> Its value is meaningless until the ldap_init function has filled in the
> pointer with the address of the LDAP structure, which is in memory
> obtained by ldap_init. There is no way to tell ldap_init to use any
> other memory for the LDAP structure. If you call ldap_init more than
> once with the same pointer as the returned value, without calling
> ldap_unbind to free the memory, ldap_init will replace the address in
> that pointer with a new address of another LDAP structure, and you will
> have no way to free the memory used by the first LDAP structure. (Well,
> you could save a copy of the pointer first, but when would you intend
> to use that copy and free the memory?) That's probably the "obvious
> memory leak" you referred to. I'm not sure if you already understand
> that, or if this is new information to you.
> 
> I don't understand why your program would ever need to use *ld in an
> assignment or in memcpy(). Perhaps you are mistaken in even attempting
> to do that, in which case there is no point in trying to make the
> assignment work.
> 
> You mentioned "thousands of calls". If this statement:
> ld = bind_adlds(hostname, container, msg) ;
> is the one that will run thousands of times, I see a problem with that.
> You probably don't want to change pointer ld thousands of times,
> especially without intervening calls to ldap_unbind. If all of the
> ldap_search calls are for the same hostname, you should assign a value
> to ld one time, using ldap_init or a function of your own that uses
> ldap_init, and perhaps also call ldap_simple-bind one time, and then,
> for the thousands of calls, call a different function that takes ld as
> an argument to perform the lap_search. Lastly, call ldap_unbind to free
> the LDAP structure.
> 
> If this is giving you a better understanding of the functions, perhaps
> you will dec

Re: C newbie - pass a LDAP handle out to calling routine

[Gibney, Dave]

First, thanks for the display in hex, that will help me a lot in future C (if 
I'm ever here again after this project)

I've found the discussion of cast in the FM, it is several chapters down from 
where I was in a straight thru read of the Language reference.  It looks like 
this will let me make progress.

I said a language is a language and it's true, but I also know it takes a lot 
of practice to become fluent. I may not see C again for years once I get this 
thing working. I really appreciate the help the listserves can provide/

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Don Poitras
> Sent: Friday, November 04, 2011 3:55 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: C newbie - pass a LDAP handle out to calling routine
> 
> Dave,
>   You need to cast to a pointer type that memcpy (or whatever) can
> handle. e.g.
> 
>  memcpy(foo, *((char *) ld), 10);
> 
> If you want to use this a lot, it might be better to just copy
> to a pointer of another type:
> 
>  char *bar;
> 
>  bar = (char *) ld;
>  memcpy(foo, *bar, 10);
> 
> Also, I find it beneficial to display addresses in hex. e.g.
> 
> printf("ld before bind   :%08X\n",ld);
> 
> In article <0DE6A9840123E547B061AC5B6765C0261C148A@EXMB-
> 05.ad.wsu.edu> you wrote:
> >   This is my first experience with C, but a language is a language after the
> 3rd or 4th :)
> > I'm calling C for LDAP queries from Natural (Software AG "4"GL) in batch.
> And it works, sort of.
> > One FM is IBM Tivoli Directory Server Client Programming for z/OS
> 
> >   If I use the sequence ldap_init, ldap_simple_bind_s, ldap_search,
> ldap_unbind, it gets overloaded after 5 calls at the speed of batch. If I 
> leave
> out the unbind, it works for thousands of calls, but there is an obvious
> memory leak.
> >   So, I want to anchor the ldap handle in the main driving program. I made a
> simple C stub:
> >
> > extern int ret2nat (int  *back_value, LDAP *ld, char *msg)
> > #include 
> 
> > In ldap.h there is:
> > typedef struct ldap LDAP;
> 
> > The examples use:
> > LDAP * ld;
> > To declare an ldap_handle which according to the listing is an:
> > ld  6270-1:1931 Class = parameter, Length = 4
> > Type = pointer to incomplete struct ldap
> >
> > I have a function:
> > LDAP * bind_adlds(char *hostname, char *container, char *msg)
> > And I call it:
> > printf("ld before bind   :%d\n",ld);   /* ld before bind   
> > :286352012
> > ld = bind_adlds(hostname, container, msg) ;
> > printf("ld after bind:%d\n",ld);/* ld after bind
> > :283317144
> 
> > but the value is not returned to the caller of ret2nat.
> >
> > Any attempts to use *ld in an assignment or even memcpy() get a complier
> message:
> > ERROR CCN3285 /u/ldap/test.c:46The indirection operator cannot be
> applied to a pointer to an incomplete struct or union.
> > Or
> > WARNING CCN3068 /u/ldap/test.c:46Operation between types "int*"
> and "pointer to an incomplete type" is not allowed.
> 
> > As I said, I am just learning how to spell C. I know I am fighting some 
> > kind of
> battle of types. I welcome even derisive comments, if in the end thay help.
> 
> > Dave Gibney
> > Information Technology Services
> > Washington State University
> 
> --
> Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
> sas...@sas.com   (919) 531-5637Cary, NC 27513
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

C newbie - pass a LDAP handle out to calling routine

[Gibney, Dave]

  This is my first experience with C, but a language is a language after the 
3rd or 4th :)
I'm calling C for LDAP queries from Natural (Software AG "4"GL) in batch. And 
it works, sort of.
One FM is IBM Tivoli Directory Server Client Programming for z/OS

  If I use the sequence ldap_init, ldap_simple_bind_s, ldap_search, 
ldap_unbind, it gets overloaded after 5 calls at the speed of batch. If I leave 
out the unbind, it works for thousands of calls, but there is an obvious memory 
leak.
  So, I want to anchor the ldap handle in the main driving program. I made a 
simple C stub:
 
extern int ret2nat (int  *back_value, LDAP *ld, char *msg)
#include 

In ldap.h there is: 
typedef struct ldap LDAP;

The examples use:
LDAP * ld;   
To declare an ldap_handle which according to the listing is an:
ld  6270-1:1931 Class = parameter, Length = 4   
Type = pointer to incomplete struct ldap

I have a function:
LDAP * bind_adlds(char *hostname, char *container, char *msg)
And I call it:  
printf("ld before bind   :%d\n",ld);   /* ld before bind   :286352012   
ld = bind_adlds(hostname, container, msg) ; 
printf("ld after bind:%d\n",ld);/* ld after bind:283317144  
 

but the value is not returned to the caller of ret2nat.
 
Any attempts to use *ld in an assignment or even memcpy() get a complier 
message:
ERROR CCN3285 /u/ldap/test.c:46The indirection operator cannot be applied 
to a pointer to an incomplete struct or union.  
 
Or
WARNING CCN3068 /u/ldap/test.c:46Operation between types "int*" and 
"pointer to an incomplete type" is not allowed.

As I said, I am just learning how to spell C. I know I am fighting some kind of 
battle of types. I welcome even derisive comments, if in the end thay help.

Dave Gibney
Information Technology Services
Washington State University

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DATA SET RESERVATION UNSUCCESSFUL

[Gibney, Dave]

This suggestion will not change the ' DATA SET RESERVATION UNSUCCESSFUL' 
situation. The answer to Lizette's question is a factor in what might be the 
correct or "better" solution.

In my experience, this message occurs when deleting a GDS (specific generation 
dataset) and something else is adding, deleting or otherwise preventing the 
required update to the GDG base entry.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Lloyd Fuller
> Sent: Thursday, November 03, 2011 12:46 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DATA SET RESERVATION UNSUCCESSFUL
> 
> Add SPACE and VOLUME parameters, and change OLD to MOD.  That way if it
> does
> exist, it will be deleted, and if it does not, it will be created and deleted 
> in
> the same step.
> 
> Use it all of the time.  You can also use UNIT=SYSDA (or some such) instead of
> VOLUME.
> 
> 
> Lloyd
> 
> 
> 
> - Original Message 
> From: "Donnelly, John P" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Thu, November 3, 2011 3:37:51 PM
> Subject: DATA SET RESERVATION UNSUCCESSFUL
> 
> We have a job that executes PGM=IEFBR14 with 40 DD cards specifying
> DISP=(OLD,DELETE,DELETE).
> From time to time we will get a JCL error because dataset reservation failed.
> Any other way we might accomplish the same event?
> 
> John Donnelly
> Texas Instruments SVA
> 2900 Semiconductor Drive
> Santa Clara, CA 95051
> 408-721-5640
> 408-470-8364 Cell
> john.p.donne...@ti.com
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Problem with add RACF certificate

[Gibney, Dave]

You can use RACDCERT CHCKCERT (or  is it CHECKCRT:) to verify the certificate 
you are trying to add.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Jake anderson
Sent: Wednesday, November 02, 2011 9:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Problem with add RACF certificate

I guess the certificate name,label name is conflicting with the one present
in RACF Database. Best is to Take a backup or export the content to a
dataset. Remove the certificate from the RACF DB with RACDCERT DELETE
command. Then perform all the steps to add the newly signed certificate.

Note : Make sure the the existing certificate is not used by anyother
application in your system. You can just check by RACDCERT CERTAUTH LIST.

HTH

On Wed, Nov 2, 2011 at 9:43 PM, Jorge Garcia  wrote:

> Hello:
>
>  We have a problem when we add a new signed trusted certificate. The step
> finished with RC 04 and the message: IRRD109I The certificate cannot be
> added.  Profile 0005.CN=Company[CA[RAIZ.O=Company is
> already defined
>
> We detail the definition steps:
>
> 1 .- Create a new ring: RACDCERT ID(TCPIPC) ADDRING(KRSEBK)
> 2 .- Create a new certificate (NONICSF):
>   RACDCERT ID(TCPIPC) GENCERT -
> SUBJECTSDN(CN('VSIS')  -
>O('MAPFRE') OU('MAPFRE VIDA') C('ES')) -
> ALTNAME(E('ZZL DGTP IT SOPORTE SISTEMAS Z/OS')) -
> WITHLABEL('CERTIF. VSIS_BK')
> 3 .- Generate a dataset from certificate:
>   RACDCERT ID(TCPIPC) -
> GENREQ(LABEL('CERTIF. VSIS_BK')) -
> DSN('SYS3.CERT.VIDA.VSIS.TCPIPC.FBK.NOMICSF')
> 4 .- We send the certificate to a trusted certificate authority. They
> return a signed certificate. We copy the content from this file to dataset
> SYS3.CERT.VIDA.VSIS.TCPIPC.FBK.NOMICSF'.
> 5 .- We add the new signed certificate to TCPIPC:
>  RACDCERT ID(TCPIPC) -
> ADD('SYS3.CERT.VIDA.VSIS.TCPIPC.FBK.NOMICSF')TRUST -
> WITHLABEL('CERTIF. VSIS_BK')
>
> It fails with IRRD109I The certificate cannot be added.  Profile
> 0005.CN=Company[CA[RAIZ.O=Company is already defined
>
> We can't connect to TN3270. Fails with a problem with the signed
> certificate authority.
>
> We remove all the keyrings active except KRSEBK. It doesn't work.
>
> Is possible delete or replace the profile?.
>
> Regards
>
> Jorge García Juanino
> Técnico de Sistemas Z/Os
> DGTP Departamento de Técnica de Sistemas
> MAPFRE
> Gobelas 47 - 49 2ª C y D
> 28023 Madrid
> Tfno: 91 581 27 34/ 618 33 35 59
> Fax: 91 581 24 01
> jgarc...@mapfre.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HSM Journal dataset is almost full

[Gibney, Dave]

We have automation issue the backvol command when the message occurs. 

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Uriel Carrasquilla
> Sent: Wednesday, October 26, 2011 12:26 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: HSM Journal dataset is almost full
> 
> I made the wrong comment.  the "F DFSMSHSM,BACKVOL CDS" command is
> running on a schedule.  When it runs, last time was yesterday, the
> HSM1.JRNL dataset does get reset to empty.  In my case, it is allocated with
> 150 CYLS and since yesterday it has used up 22 CYLS.
> The problem is that I am getting hit with messages that it is 80% full quite
> often.  So my thinking is that I either run the BACKVOL command more often
> or increase the size of the HSM1.JRNL dataset.
> If I was to increase the size of the HSM1.JRNL dataset, what would be the
> best practice?
> Run the BACKVOL CDS command, take down DFSMSHSM, increase the size
> of the JRNL file size (after deleting and re-allocating) or is it something 
> else?
> Thanks.
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf
> of McKown, John [john.mck...@healthmarkets.com]
> Sent: Wednesday, October 26, 2011 12:48 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: HSM Journal dataset is almost full
> 
> I think the OP was wonder how to expand the size of the journal so that it
> would not fill up as quickly. Not how to automate doing the backvol
> command or how to do the backvol cds command. He knows how, he just
> wants to do it less often. At least, that's how I read his intent.
> 
> --
> 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: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould
> > Sent: Wednesday, October 26, 2011 11:33 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: HSM Journal dataset is almost full
> >
> >  Uriel,
> > The real question you should be looking for is to why the
> > automatic jobs that should be running are not.
> >
> > Ed
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CRLF in Unix being translated on Mainframe to x'25'

[Gibney, Dave]

Listen to Peter. :)

Ok, if you are using a batch job on z/OS, then you are the client for that 
transfer. If the file on Windows has the CRLF (that is Notepad works), then a 
ASCII/EBCIDIC transfer to a FB or VB file with a large enough LRECL should 
work. You can use the LOCSITE to subcommand to control this.

Which end is the client on the Unix to Windows? You need to make sure the NL to 
CRLF "translation" occurs. We use MoveITFreely for Windows command files. I 
think it handles this automatically, but it is other people that set that end 
up around here.

Dave Gibney
Information Technology Services
Washington State University

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Lizette Koehler
> Sent: Monday, October 24, 2011 2:41 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CRLF in Unix being translated on Mainframe to x'25'
> 
> >
> >BTW, do local politics allow going directly to z/OS instead of
> >therough the W2008 box?
> >
> 
> 
> 
> As for politics.
> It must be done this way, Unix, to Win2008, to Mainframe.
> 
> No options here.
> 
> I have tried several tests.  Either I only get one record up on the mainframe
> or the data is definately in bin format when it arrives.  I have tried BIN FB,
> BIN VB,  ASCII FB and ASCII VB.  So far the 44 records I have to test with are
> just not behavingin.
> 
> The odd thing is that NOTEPAD cannot read this file well.  It wraps it (yes 
> tried
> the WRAP FORMAT in Notepad no luck).  So I can see the records circle
> around in the notepad window.
> 
> However, Notepad++ sees it as individual records.
> 
> Still plugging along.  I am trying the cmd prompt from my desktop to the
> mainframe.  However, it is possible that this file will be brought up via a 
> batch
> job on the mainframe.  I am trying that now.
> 
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

LDAP from C with CINET - z/OS 1.11 xposted

[Gibney, Dave]

I am calling ldap_xxx services from (ref IBM Tivoli Directory Server Client 
Programming for z/OS) from IBM C.   

I have a CINET environment, the ldap calls are working fine using my default 
TCPIP region. In my RTM, I haven't found a way to tell the ldap_xxx to use one 
of the other TCPIP(n) regions. I know I can do this via the SYSTCPD DD, but I 
was hoping to find a way to do it in the C code.

Any help will be appreciated even if it confirms I can't really do what I want.


Dave Gibney
Information Technology Services
Washington State University

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC331I 050-030(VVDSFULL, PROD06)

[Gibney, Dave]

If it's SMS, the VVDS has data for non-VSAM also. I agree with you. Stop new 
allocations (DISNEW), Carefully move everything (make take several passes), 
when it's empty, re-init it and allocate a sufficiently large VVDS on it.   

I still always allocate a VVDS right after I init a new volume. I do not let 
the automatic allocation happen. 

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Linda Mooney
> Sent: Tuesday, October 18, 2011 3:42 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEC331I 050-030(VVDSFULL, PROD06)
> 
> Hi Esmie,
> 
> 
> 
> If you take the all of the VSAM datasets off of the volume, you can delete
> the VVDS (I can send you the IDCAMS if you want) and allocate a new,
> bigger one on the same volume.
> 
> 
> 
> Personally, I would not zap a VVDS.  I know that some probably would, but
> not me , I wouldn't.  I would stop new allocations.   I would move off the 
> data
> to another volume using a logical copy, not a physical copy - CA-Disk, FDRDSF,
> DSS .  I recommend taking a look at the size of the VTOC and the VTOC index
> as well.  Since the VVDS is too small the others are likely to be too small
> too.  The VVDS should be cleaned out before and deleted BEFORE  you re-init
> the volume.   I can help you with the VVDS clean out, if you want.  I have
> done many of them.
> 
> 
> 
> Do you have QuickRef?  Its DASD free space panel will show you the
> percentage of free space in the VTOC and index.  It works with single
> volume, SMS pool, or volser pattern.  It's an easy way to check a bunch of
> volumes.
> 
> 
> 
> Having one volume with a too small VVDS sug gests that there are probably
> more out there.  Folks often take the defaults and new folks often code sizes
> according to the  way it is in the book.  The more datasets that may be
> assigned to a volume, the bigger VTOC, VTOC index and VVDS will be
> needed.  It is better to have all three generously sized rather than too 
> small.
> 
> 
> 
> HTH,
> 
> 
> 
> Linda
> 
> 
> 
> 
> From: "esmie moo" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, October 18, 2011 3:48:23 AM
> Subject: Re: IEC331I 050-030(VVDSFULL, PROD06)
> 
> Linda,
> 
> I did what you asked.  I ran the report and moved 90 dsns from the volume,
> however the problem still persists.  I was told to check OEM option to ZAP
> the VVDS.  I would like to try that out but I am not sure where I should look
> for it.
> 
> 
> 
> From: Linda Mooney 
> To: IBM-MAIN@bama.ua.edu
> Sent: Monday, October 17, 2011 4:06:12 PM
> Subject: Re: IEC331I 050-030(VVDSFULL, PROD06)
> 
> Hi Esmie,
> 
> 
> 
> If you want to get a look at the contents of the VVDS, you can run this -
> 
> 
> 
> //STEP1   EXEC  PGM=IDCAMS
> //SYSPRINT DD  SYSOUT=*
> //SYSIN    DD  *
>    PRINT -
>     INDATASET(SYS1.VVDS.Vvolser) -
>     COUNT(1)
> 
> 
> It should shed some light on what has filled it up.
> 
> 
> HTH,
> 
> 
> 
> Linda
> 
> 
> 
> - Original Message -
> 
> 
> From: "esmie moo" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Monday, October 17, 2011 11:59:24 AM
> Subject: IEC331I 050-030(VVDSFULL, PROD06)
> 
> Good Afternoon Gentle Readers
> 
> I am trying to trouble shoot the following problem : IEC331I 050-
> 030(VVDSFULL, PROD06)
> According to the message error explanation it says that the VVDS is
> full.  When I check via ISPF 3.4 is shows that it is a 1 ext.  The VVDS was 
> built
> at TRACKS(30 1).  To fix the problem the doc says to move dsns off that
> volume.  I tried that but the problem persists when the system is trying to
> allocate a dsn on the volume.  Since the volume is SMS managed (phew), I
> put it at DISNEW.  The doc says to backup the volume, and reinitialize it 
> with a
> larger VVDS.
> Is there something else I can try before I try the doc's recommendation?
> 
> Thanks in advance.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua

Re: IEC331I 050-030(VVDSFULL, PROD06)

[Gibney, Dave]

Good point, thank you.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Staller, Allan
> Sent: Tuesday, October 18, 2011 2:03 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEC331I 050-030(VVDSFULL, PROD06)
> 
> Do not use process(SYS1) w/o excluding the VVDS and the VTOCIX (Check
> the syntax, Done from memory).
> 
> COPY DATASET(INCLUDE(**)
> EXCLUDE(SYS1.VTOCIX.VPROD06,
> SYS1.VVDS.PROD06) -
> ) -
>   INDY( -
>(PROD06) -
>)-
>   EXCLUDE(SYS1.VTOCIX.VPROD06 -
>SYS1.VVDS.PROD06) -
>   ALLEXCP  -
>   ALLDATA(*)   -
>   ADMIN-
>   CATALOG  -
>   DELETE   -
>   PROCESS(SYS1)-
>   PURGE-
>   SPHERE
> 
> 
> With PROG06 in DSNEW status, run:
> //ADRDSSU   EXEC PGM=ADRDSSU,REGION=5M,
> // TIME=1439 ,PARM='TYPRUN=SCAN'
> //SYSPRINT DD SYSOUT=*
> //SYSINDD *
>   COPY DATASET(INCLUDE(**)) -
>   INDY( -
>(PROD06) -
>)-
>   ALLEXCP  -
>   ALLDATA(*)   -
>   ADMIN-
>   CATALOG  -
>   DELETE   -
>   PROCESS(SYS1)-
>   PURGE-
>   SPHERE
> 
> Which will move everything it can off of PROD06 and keep it in the same
> SMS pool.
> 
> Then determine why whatever is left wouldn't move, remove the inhibitor,
> and move it.
> 
> When volume is empty, reinit.
> 
> IMO, any of the other methods suggested include unneeded risk.
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC331I 050-030(VVDSFULL, PROD06)

[Gibney, Dave]

With PROG06 in DSNEW status, run:
//ADRDSSU   EXEC PGM=ADRDSSU,REGION=5M,  
// TIME=1439 ,PARM='TYPRUN=SCAN' 
//SYSPRINT DD SYSOUT=*   
//SYSINDD *  
  COPY DATASET(INCLUDE(**)) -
  INDY( -
   (PROD06) -
   )-
  ALLEXCP  - 
  ALLDATA(*)   - 
  ADMIN- 
  CATALOG  - 
  DELETE   - 
  PROCESS(SYS1)- 
  PURGE- 
  SPHERE

Which will move everything it can off of PROD06 and keep it in the same SMS 
pool.

Then determine why whatever is left wouldn't move, remove the inhibitor, and 
move it.

When volume is empty, reinit. 

IMO, any of the other methods suggested include unneeded risk.

Dave Gibney
Information Technology Services
Washington State University

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: RSU Order using Shop zSeries Website

[Gibney, Dave]

It's all there in the SMP/E manual.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
saurabh khandelwal
Sent: Tuesday, October 11, 2011 8:59 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: RSU Order using Shop zSeries Website

Hello,
   I have never used this feature to order selectively. I always
used to order full package.  Can you please suggest me the way or point any
redbook, which can help me to do this task.

Regards
Saurabh


On Wed, Oct 12, 2011 at 9:25 AM, Skip Robinson wrote:

>  I think a lot of us are saying, Aha. R12 fully supports
> RECEIVEFROMNETWORK, a far superior means of pulling maintenance. RFN sends
> a bit map of your CSI to Shopz so that he can selectively send you only
> the fixes that you do not already have on your system. The result should
> be a far smaller package than you are currently being shipped.
>
> .
> .
> 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:   saurabh khandelwal 
> To: IBM-MAIN@bama.ua.edu
> Date:   10/11/2011 08:48 PM
> Subject:Re: RSU Order using Shop zSeries Website
> Sent by:IBM Mainframe Discussion List 
>
>
>
> Hello Experts,
>   Sorry for Typo maistake. It is actually z/OS 1.12
> system . I am trying to downlaod RSU for z/OS 1.12 system only.
>
> Regards
> Saurabh
>
> On Tue, Oct 11, 2011 at 12:50 PM, saurabh khandelwal <
> sourabhkhandelwal...@gmail.com> wrote:
>
> > Hello Experts,
> >  I am trying to order z/OS 1.2 RSU package. But
> > somehow its getting rejected  with below error.
> >
> > order has been  rejected because Package size exceeded the "Electronic"
> > threshold
> >
> > When we order any RSU, it ask for maximum size of packet , which I have
> > selected 5 GB max.
> > It also ask for Splitting the order into 50MB pieces but after that also
> I
> > am getting below error.
> >
> > Package size exceeded the "Electronic" threshold < Please
> > re-order w/o requisites or specify an "Alternate" media Customer BITMAP
> is
> > being used for this order Package contained 5715 fixes with 10,533,198
> > Kilo-bytes of data This Package contains PTF(s) with open PE-APAR(s)
> >
> >
> > Can you please help me to reorder the RSU.
> >
> >
> > --
> > Thanks & Regards
> > Saurabh Khandelwal
> >
>
>
>
> --
> Thanks & Regards
> Saurabh Khandelwal
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Thanks & Regards
Saurabh Khandelwal

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: RSU Order using Shop zSeries Website

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Chase, John
> Sent: Tuesday, October 11, 2011 3:00 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: RSU Order using Shop zSeries Website
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave
> >
> > Check out RECEIVE ORDER:
> >
> >
> > RECEIVE SYSMODS HOLDDATA
> > ORDER(ORDERSERVER(ORDSRVR)
> > CONTENT(ALL))
> > DELETEPKG.
> 
> I was going to suggest that, too, but best I can recall RECEIVE ORDER
> was not available in the SMP/E release that comes with z/OS 1.2.
> 
I'm sorry, if I missed attempts at back level maintenance, but I am surprised 
Shopz is taking orders at z/OS 1.2 :)

Dave Gibney
Information Technology Services
Washington State University
> -jc-
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: RSU Order using Shop zSeries Website

[Gibney, Dave]

Check out RECEIVE ORDER:


RECEIVE SYSMODS HOLDDATA  
ORDER(ORDERSERVER(ORDSRVR)
CONTENT(ALL)) 
DELETEPKG.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of saurabh khandelwal
> Sent: Tuesday, October 11, 2011 2:02 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: RSU Order using Shop zSeries Website
> 
> Hello Gerry,
>  But I dont see the option to select older RSU level.
>  Once we order RSU using Sope zSeries website, it just ship us the latest
> RSU level available.
> 
> Can you please tell me the procedure to order any specific RSU level.
> 
> Regards
> Saurabh
> 
> On Tue, Oct 11, 2011 at 2:29 PM, Gerry Tracey
> wrote:
> 
> > Hi Saurabh
> >
> > Yes you can select older RSU levels and you can also tailor the request by
> > selecting specific products or FMIDs.
> >
> > Gerry
> >
> >
> > >Is it possible to order older RSU. For example if  I
> > am
> > >at RSU level 1005 and the current level of RSU which is getting shipped
> > with
> > >this order is 1109 and If I want to oder the RSU level 1103. Is it really
> > >possible .
> >
> >
> >
> > ..For low fares and great deals on hotels, car hire and travel insurance
> > visit http://www.aerlingus.com
> >
> >
> **
> *
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed.  Any review, dissemination or other use of, or taking
> > of any action in reliance upon, this information by persons or entities
> > other than the intended recipient is prohibited.If you have received
> > this email in error please notify the sender immediately and delete
> > the material.
> >
> >
> **
> *
> > Aer Lingus Limited
> > Registered in Ireland
> > Company Number 9215
> > Registered Office at Dublin Airport, Dublin,Ireland.
> >
> >
> **
> *
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> 
> 
> 
> --
> Thanks & Regards
> Saurabh Khandelwal
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ACS dataclas- clarification

[Gibney, Dave]

Picky point. DO...END in ACS routines are not loops. Otherwise, I agree, use 
writes liberally.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Lizette Koehler
Sent: Friday, October 07, 2011 4:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ACS dataclas- clarification

Jags,

For debugging ACS code it is always helpful to add WRITE statements to your
DO LOOPS.

So 
   when (&dsn eq &oedsn)
 do
 set &dataclas eq 'omvs'
 exit
 end

Becomes
   when (&dsn eq &oedsn)
 do
 write 'The dsn is &DSN and the class is &dataclas'
 set &dataclas eq 'omvs'
 write 'The dsn is &DSN and the class is &dataclas after set'
 exit
 end


Do this for each WHEN DO END process and it will hopefully provide the
answers.

Always use WRITE statements a lot when working with ACS Code.  Once it
works, you may wish to leave in a few but not all.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Limit the number of FTP connection attempts;

[Gibney, Dave]

Thanks Chris, from your quote, that looks like what I want, but

  Last I looked (some years ago now)  at IDS for z/OS Communication Server (IP) 
(or whatever the precise name is :)+
I thought I needed to get Policy Agent up first. And something else before 
that. I'll look more tomorrow, This was only one event on a busier than usual 
Monday. 
  Strangely, none of today's problems related to the changes we made over the 
weekend.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Chris Mason
> Sent: Monday, October 03, 2011 4:58 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Limit the number of FTP connection attempts;
> 
> Dave
> 
> I'd say your DoS approach was, if not the only way, one way.
> 
> You need to check through Chapter 18, "Intrusion Detection Services" in the
> Configuration Guide.
> 
> Maybe the following:
> 
> 
> 
> 2.9.3.1 TR TCP
> 
> IDS TR policies for TCP ports limit the total number of connections an
> application has active at one time. This can be used to limit the number of
> address spaces created by forking applications such as FTPD and otelnetd. A
> fair share algorithm is also provided based on the percentage of remaining
> available connections already held by a source IP address.
> 
> 
> 
> If you post in IBMTCP-L you may expand the net for folk who have had to
> handle something similar.
> 
> Chris Mason
> 
> On Mon, 3 Oct 2011 20:05:20 +, Gibney, Dave 
> wrote:
> 
> >Hello, asking for suggestions.
> >
> >I have a "distributed" product being installed here that I don't have much
> control over.
> >Today, in a development environment, it looped trying to establish ftp
> connections to a z/OS LPAR. z/OS relatively quickly reached: IEA602I ADDRESS
> SPACE CREATE FAILED.  MAXUSERS WOULD HAVE BEEN EXCEEDED
> >
> >I am RTFM for a way to limit FTP from running away like this, but I thought I
> would ask here also. It occurs to me that this could be used as a DoS attempt.
> Before I was notified, others had already IPL'd, the looping entity was still
> there and we had lost access via SYSVIEW, EJES (standalone VTAM is really
> nice, thanks Ed) or anything else.
> >
> >I will look at procedural changes also. :)
> >
> >Dave Gibney
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Limit the number of FTP connection attempts;

[Gibney, Dave]

Hello, asking for suggestions.

I have a "distributed" product being installed here that I don't have much 
control over.
Today, in a development environment, it looped trying to establish ftp 
connections to a z/OS LPAR. z/OS relatively quickly reached: IEA602I ADDRESS 
SPACE CREATE FAILED.  MAXUSERS WOULD HAVE BEEN EXCEEDED

I am RTFM for a way to limit FTP from running away like this, but I thought I 
would ask here also. It occurs to me that this could be used as a DoS attempt. 
Before I was notified, others had already IPL'd, the looping entity was still 
there and we had lost access via SYSVIEW, EJES (standalone VTAM is really nice, 
thanks Ed) or anything else. 

I will look at procedural changes also. :)

Dave Gibney
Information Technology Services
Washington State University

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FORCE ARM

[Gibney, Dave]

Others with real knowledge will chime in. I think it is something like "allow 
recovery (or maybe resource) managers".
A FORCE,ARM allows the application specified recovery and resource clean-up 
routines (if any) to run. FORCE without ARM just jerks everything out at once :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Phil Smith
> Sent: Thursday, September 22, 2011 4:51 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: FORCE ARM
> 
> Ok, I'll probably be sorry I opened this can of worms, but: WTF does ARM
> stand for on FORCE ARM? "If you're wrong, they'll cut one off"? Short for
> ARM? ARMy grade? alARM? All Right Mom?
> 
> Did some searching, no joy. No fair Googling *including the string that you
> already know it stands for* and finding it!
> 
> ...phsiii
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TCP/IP Stacks

[Gibney, Dave]

We are in the "long" process of "zoning" our servers into different levels of 
data "sensitivity". 

My mainframe supports applications in several of the "zones". The choice to go 
with multiple stacks with multiple ips in the various zones may not have been 
superior to the alternative of managing firewall rules, but it is the route we 
chose.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Lindy Mayfield
> Sent: Monday, September 19, 2011 9:59 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Multile TCP/IP Stacks
> 
> Hello
> 
> I would like to find out or understand why multiple TCP/IP stacks are used on
> some machines.  I've read through some of the IBM documentation, but I still
> don't get it.
> 
> Thanks
> Lindy
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

it's

[Gibney, Dave]

Hi Ed, you are saying you see no 39 in either this subject line and in the 
quoted note below. Then your client is doubly broken :)

Dave Gibney
Information Technology Services
Washington State University

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Ed Gould
> Sent: Wednesday, September 14, 2011 10:35 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SMS compressed VSAM datasets
> 
> 
>  I have no idea what the issue is. The email you sent back to me does not
> contain the characters you indicated.
> A friend suggested it's a ISP issue. I will try using m other client and 
> see
> if the issue follows.
> 
> 
> Ed
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SMS compressed VSAM datasets

[Gibney, Dave]

Something is wrong with Ed's email that causes single quote (or apostrophes) to 
show as "',"

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Mingee, David
Sent: Tuesday, September 13, 2011 7:51 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMS compressed VSAM datasets

Ed,  Not that I know of.  BTW, what is ',t   mean?  I see it frequently, is 
it encrypted cursing? hahaha




David L. Mingee
Principal Systems Administrator
Indianapolis Production Control 
Data Center Operations / Operations Technical Support

Work Ext  782-6460
Work Direct Dial  317 581-6460
Home 317 598-0919 / Cell 317 341-0885



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ed Gould
Sent: Tuesday, September 13, 2011 10:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMS compressed VSAM datasets

 David,

Correct me if I am wrong but doesn't DFDSS invoke idcams under the covers?

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: why did i just need to sign in to gmail, just to view ibm-main? is it proprietary now?

[Gibney, Dave]

Strangely enough, my use of IBM-MAIN has not needed to change for years. Of 
course I am subscribed directly to the list and receive each message.

No need to adapt to changes gratuitous or otherwise to any fancy webby 
interface :)

Dave Gibney
Information Technology Services
Washington State University

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: load mmodules copying to other site

[Gibney, Dave]

The standard IBM utility to unload a PDS is IEBCOPY. TRANSMIT uses IEBCOPY to 
unload the PDS and then encapsulates in in a transmittable format.

This suggestions given in this thread (and dozens of others in the past) work. 
KIS

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Cris Hernandez #9
> Sent: Wednesday, August 31, 2011 5:06 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: load mmodules copying to other site
> 
> I'd start with standard IBM utility (iebupdte) to unload the pds to a 
> sequential
> file, send it, then use same utility to create a new pds (or update) from the
> sequential file.  if it gets screwed up in transmit, deal with it when it 
> happens,
> the messages in the utility output should indicate such when reloaded to
> pds, plus they won't execute.  been a while for me, but it once was standard
> fare when cobol applications were replicated across multiple sites.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: load mmodules copying to other site

[Gibney, Dave]

In:
UNIX System Services  Command Reference  Document Number SA22-7802-12
There is:
CKSUM cksum -- Calculate and display checksums and byte counts

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Steve Conway
> Sent: Wednesday, August 31, 2011 12:09 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: load mmodules copying to other site
> 
> Thanks, Tom.
> 
> I was responding to Gil's post, in which he was going z/OS -> desktop ->
> z/OS, no mention of GIMZIP / GIMUNZIP.  Guess I just missed the tie-in.
> 
> Although a z/OS checksum would make dealing with certain auditors easier
> to satisfy...
> 
> 
> Cheers,,,Steve
> 
> Steven F. Conway, CISSP
> LA Systems
> z/OS Systems Support
> Phone: 703.295.1926
> steve_con...@ao.uscourts.gov
> 
> 
> 
> From:   Tom Marchant 
> To: IBM-MAIN@bama.ua.edu
> Date:   08/31/2011 02:56 PM
> Subject:Re: load mmodules copying to other site
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> On Wed, 31 Aug 2011 14:46:50 -0400, Steve Conway wrote:
> 
> >What would you use to do a checksum on z/OS?
> 
> If you use GIMZIP/GIMUNZIP as Art suggested, a checksum will be created
> and checked.
> 
> --
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: testing z/OS 1.8 on a Z/196 or z/114

[Gibney, Dave]

Before I lost three people, we were planning and partway there on upgrading to 
Adabas 8. One database in one sandbox is actually running Adabas 8.1.3

The usual path (or at least how we've always done it :) is to upgrade the SVC 
first as it has generally been backward compatible.

Who knows, I may still get an Adabas upgrade accomplished before the 5 years to 
no mainframe is over :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Linda Mooney
> Sent: Tuesday, August 30, 2011 4:39 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: testing z/OS 1.8 on a Z/196 or z/114
> 
> Hi Dave,
> 
> 
> 
> Im curious, why the 8.1.4 ADABAS SVC with the 7.4.4 product level?
> 
> 
> Thanks,
> 
> 
> 
> Linda
> 
> 
> - Original Message -
> 
> 
> From: "Dave Gibney" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, August 30, 2011 4:28:51 PM
> Subject: Re: testing z/OS 1.8 on a Z/196 or z/114
> 
> I'm running Adabas 7.4.4 on a z9-BC under z/OS 1.11
> We're running a 8.1.4 version of the Adabas SVC. No Complete.
> 
> I knew lots of $ were in the equation since it is Software AG you are
> dealing with.
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu]
> On
> > Behalf Of Brian Westerman
> > Sent: Tuesday, August 30, 2011 4:21 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: testing z/OS 1.8 on a Z/196 or z/114
> >
> > Actually, that could be a tremendous help.  They are running Adabas
> > 7.4.3+PTFs (which makes them technically 7.4.4, according to SAG), and
> z/OS
> > 1.10 is fully supported on the z/196 and z/114 without the lifecycle
> extension.
> > Obtaining a copy of z/OS 1.10 is problematic, but doable.
> >
> > Are you guys running Com-Plete as well, and if so, what release?
> >
> > Thanks again,
> >
> > Brian
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: testing z/OS 1.8 on a Z/196 or z/114

[Gibney, Dave]

I'm running Adabas 7.4.4 on a z9-BC under z/OS 1.11
We're running a 8.1.4 version of the Adabas SVC. No Complete.

I knew lots of $ were in the equation since it is Software AG you are 
dealing with.

Dave Gibney
Information Technology Services
Washington State University

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Brian Westerman
> Sent: Tuesday, August 30, 2011 4:21 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: testing z/OS 1.8 on a Z/196 or z/114
> 
> Actually, that could be a tremendous help.  They are running Adabas
> 7.4.3+PTFs (which makes them technically 7.4.4, according to SAG), and z/OS
> 1.10 is fully supported on the z/196 and z/114 without the lifecycle 
> extension.
> Obtaining a copy of z/OS 1.10 is problematic, but doable.
> 
> Are you guys running Com-Plete as well, and if so, what release?
> 
> Thanks again,
> 
> Brian
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Spool volumes and SMS

[Gibney, Dave]

Probably never will. Unless an all SMS mandate appears for future z/OS.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Mike Liberatore
> Sent: Saturday, August 27, 2011 3:39 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Spool volumes and SMS
> 
> Never did.
> --Original Message--
> From: Ed Gould
> Sender: IBM Mainframe Discussion List
> To: IBM-MAIN@bama.ua.edu
> ReplyTo: IBM Mainframe Discussion List
> Subject: Spool volumes and SMS
> Sent: Aug 27, 2011 5:50 PM
> 
> Just curious as to a general consensus, do you use SMS for spool volumes?
> 
> Ed
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 
> Sent from my Verizon Wireless BlackBerry
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL Changes and SMS and Not Cataloged Datasets

[Gibney, Dave]

I thought the same, so I looked in AMS for Catalogs. As of z/OS 1.11, ALTER 
authority to the dataset seems all that is required. IMO, there should be an 
STGADMIN.IGG profile for disallowing this function.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Scott Rowe
> Sent: Friday, August 26, 2011 2:36 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL Changes and SMS and Not Cataloged Datasets
> 
> How are they uncataloging SMS datasets?  I could have sworn a normal user
> could not accomplish that without special privileges.  Since I no longer
> have a system, I can't verify this, but I thought a DELETE NOSCRATCH for an
> SMS dataset failed unless you had proper authorization.
> 
> On Fri, Aug 26, 2011 at 4:50 PM, Ted MacNEIL  wrote:
> 
> > >This poor practice was something instilled in the Tata contractors we have
> > employed.
> >
> > Simple answer to that: don't hire them again.
> >
> > Long before SMS, in 1981 (when I started), we had utilities to
> > automatically delete uncatalogued datasets.
> >
> > There has been no reason, aside from SYSRES, JES SPOOL and the like, for
> > uncatalogued datasets for aeons!
> > -
> > Ted MacNEIL
> > eamacn...@yahoo.ca
> > Twitter: @TedMacNEIL
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> 
> CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
> confidential and privileged information intended only for the addressee.
> If you are not the intended recipient, please be advised that you have
> received this material in error and that any forwarding, copying, printing,
> distribution, use or disclosure of the material is strictly prohibited.
> If you have received this material in error, please (i) do not read it,
> (ii) reply to the sender that you received the message in error, and
> (iii) erase or destroy the material. Emails are not secure and can be
> intercepted, amended, lost or destroyed, or contain viruses. You are
> deemed
> to have accepted these risks if you communicate with us by email. Thank
> you.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SMS and Not Cataloged Datasets

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Ted MacNEIL
> Sent: Friday, August 26, 2011 11:33 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SMS and Not Cataloged Datasets
> 
> >These datasets turn up not cataloged because of statements in our
> production JCL which specify things like NOSCRATCH NOERASE for a simple
> dataset.
> 
> I would change the JCL.

I have to agree, I have trouble thinking of an excuse for routine NOSCRATCH 
NOERASE even back when. In an SMS world, it just doesn't make sense and I would 
take measures to stop it if I found it here.

Dave Gibney
Information Technology Services
Washington State University

> -
> Ted MacNEIL
> eamacn...@yahoo.ca
> Twitter: @TedMacNEIL
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYNCH[X] vs LINK[X]

[Gibney, Dave]

The is nothing about MVCL that violates refresh/reuse -ability.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Micheal Butz
> Sent: Tuesday, August 23, 2011 12:10 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SYNCH[X] vs LINK[X]
> 
> In a earlier post John Gilmore wrote as long as the copy is
> refershable reusable the Info is kept in the CDE
> 
> Sent from my iPhone
> 
> On Aug 23, 2011, at 2:47 PM, Gerhard Postpischil 
> wrote:
> 
> > On 8/23/2011 1:05 PM, Micheal Butz wrote:
> >> If I have a peice of code that was MVCL somewere it can'nt be
> >> the object of synch/synch
> >
> > OK, I'll bite - why not?
> >
> > Gerhard Postpischil
> > Bradford, VT
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IGD06023I STORAGE GROUP ZFSCLASS IS NOT REFERENCED BY THE STORAGE GROUP ACS ROUTINE

[Gibney, Dave]

Starting with:
WHEN (&HLQ = &ZFS_HLQ)  /*  MANAGE MULTI VOLUME ZFS DATA SETS
It's all comment until the */ on the last line.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Darth Keller
> Sent: Thursday, August 04, 2011 8:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IGD06023I STORAGE GROUP ZFSCLASS IS NOT REFERENCED BY
> THE STORAGE GROUP ACS ROUTINE
> 
> Your validate seems to be indicating that this code is not actually part
> of your translated routines.
> 
> I'd say that either -
> 
> 1.  This code was never actually translated to the SCDS that you are using
> for this Validate .
> 
> 2. Your code actually ends before this section.  Take a close look at the
> output of your translate.
> 
> #1 is probably the most likely.
> 
> 
> HTH's
> ddk
> 
> 
> 
> 
> 
> From:   Lim Ming Liang 
> To: IBM-MAIN@bama.ua.edu
> Date:   08/04/2011 10:14 AM
> Subject:IGD06023I STORAGE GROUP ZFSCLASS IS NOT REFERENCED BY
> THE
> STORAGE GROUP ACS ROUTINE
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Hi,
> I am new in DFSMS, trying to do a validate against my SCDS, got a
> warning msg
> 
> IGD06023I STORAGE GROUP ZFSCLASS IS NOT REFERENCED BY THE STORAGE
> GROUP
> ACS ROUTINE
> 
> But in Storage Group ACS routine as below;
> 
> PROC STORGRP
> /**
> /
> FILTLIST HSM_HLQ INCLUDE('HFS1')
> FILTLIST ZFS_HLQ INCLUDE('ZFS')
> FILTLIST HS1_HLQ INCLUDE('CICSTS1X')
> FILTLIST SYSTEM_DATA_SET INCLUDE(SYS%.**)
> FILTLIST VALID_STORAGE_CLASS INCLUDE('HFSCLASS','DBCLASS','ZFSCLASS')
> /**
> /
> /**
> /
> /* End of FILTLIST Statements */
> /**
> /
>   SELECT
>WHEN (&HLQ = &HSM_HLQ)  /*  MANAGE MULTI VOLUME HFS DATA
> SETS */
>  DO
>SET &STORGRP = 'HFSCLASS'
>EXIT
>  END
>WHEN (&HLQ = &ZFS_HLQ)  /*  MANAGE MULTI VOLUME ZFS DATA
> SETS
>  DO
>SET &STORGRP = 'ZFSCLASS'
>EXIT
>  END
>WHEN (&HLQ = &HS1_HLQ)   /*  MANAGE HFS DATA SETS*
>  DO
>SET &STORGRP = 'DBCLASS'
>EXIT
>  END
>   END
> END  /* END OF STORAGE GROUP ROUTINE PROC */
> 
> 
> I did have ZFSCLASS referenced in the ACS source, where did I go wrong ?
> 
> --
> Regards Lim ML
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 
> 
> This e-mail message and all attachments transmitted with it may
> contain legally privileged and/or confidential information intended
> solely for the use of the addressee(s). If the reader of this
> message is not the intended recipient, you are hereby notified that
> any reading, dissemination, distribution, copying, forwarding or
> other use of this message or its attachments is strictly
> prohibited. If you have received this message in error, please
> notify the sender immediately and delete this message and all
> copies and backups thereof. Thank you.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: NOT Running DFHSM on an LPAR

[Gibney, Dave]

I am all monoplex and I don't run DFHSM in one. I get "Tape not supported" with 
an ISBF browse of a migrated dataset. And yes an HRECALL seems to be queued 
somewhere. (I'd like to know where and how to cancel, but I won't lose sleep:)

A batch job failed with an JCL error (SMS allocation failure)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Lizette Koehler
> Sent: Wednesday, August 03, 2011 12:31 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: NOT Running DFHSM on an LPAR
> 
> >I'm not sure whether you want to (a) avoid recalls or (b) avoid the CPU
> >time required to run DFSMShsm at all.
> >
> >If (a), would an ARCRPEXT exit that passed back return code 8 for every
> >recall request, indicating that DFSMShsm should purge them rather than
> >queuing them, do what you want?
> >
> >ARCRPEXT is documented in the DFSMS Installation Exits book at:
> >http://publibz.boulder.ibm.com/cgi-
> bin/bookmgr_OS390/BOOKS/dgt2c780/CCONTENTS?SHELF=EZ2ZBK0K&DN=S
> C26-7396-13&DT=20100610093321
> >
> >If (b), have you tried setting DFSMShsm to unlicensed in IFAPRDxx for
> >that LPAR to disable it (vs. simply not starting it)?  I don't know
> >whether this would do what you want but it seems easy enough to try.
> >(You can use a SET command to go back and forth without an IPL.)
> >
> >--
> 
> 
> Thanks for all the suggestions.
> 
> Changing IFAPRDxx to have DFHSM disabled did not prevent the recall from
> getting queued.
> 
> So we will probably have to run DFHSM and see how we can keep it running
> small on this LPAR.  We will be reviewing CRQ and I will review exit code in
> DFHSM.
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Gibney, Dave]

   I really wish you folks would get your semantics clear. The original problem 
and solution proves the facts without need for further discussion.

1. Take a perfectly good, LRECL=80 PDS. Maybe to be really clear, find a PDS 
with LERECL > 133.
2. trash it by pointing any SYSOUT DD to a "NEW" member.
The original problem is now there and:

3. confirm that the DSCB in the VTOC for the PDS now claims LRECL=133 (or maybe 
121).
4. Fail to browse using ISPF or read any older member using IEBGENER
5. Run IEBGENER specifying (overriding) 
LRECL=correctlrecl,BLKSIZE=correct(old)blksize) on the input DD and it works.
6. Run  IEBGENER to a new member or even the "bad"  member specifying 
(overriding) LRECL=80 (old lrecl)

7. PDS is now fixed.

Dave Gibney
Information Technology Services
Washington State University

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP from IBM's book server

[Gibney, Dave]

I really don't understand why anyone wouldn't be satisfied with Softcopy 
Librarian? Yes, it's Windows only Java :(, but it will drag down almost every 
book you could want. And if you want to play with them further, they are all 
there in your local storage.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Ed Gould
> Sent: Monday, August 01, 2011 3:53 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: FTP from IBM's book server
> 
> If I want one book at a time. It works. But there has to be a faster way.
> 
> Ed
> 
> Sent from my iPad
> 
> On Aug 1, 2011, at 4:19 PM, Cris Hernandez #9
>  wrote:
> 
> > use browser and ftp instead of http?
> >
> >
> > --- On Mon, 8/1/11, Ed Gould  wrote:
> >
> >> From: Ed Gould 
> >> Subject: FTP from IBM's book server
> >> To: IBM-MAIN@bama.ua.edu
> >> Date: Monday, August 1, 2011, 1:32 AM
> >> John had said he was able to FTP and
> >> download books from IBM's book server.
> >> I tried it and basicallly got nowhere after signing in with
> >> anonymoouse and my email address.
> >>
> >> Has anyone else been able to get the books via FTP and can
> >> they share how they did it, please?
> >>
> >> Ed
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access
> >> instructions,
> >> send email to lists...@bama.ua.edu
> >> with the message: GET IBM-MAIN INFO
> >> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >>
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Gibney, Dave]

You have yet to provide the precise text of the i/o error message. Have you 
confirmed the LRECL and RECFM are as expected? Do you have PDS from the CBT 
tape or STARTOOLS?

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 10:42 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> 
> 
> I tried it but when I try the copy command it gives me the I/O error.  Thanks
> for your suggestion.
> 
> From: John Mattson 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, July 26, 2011 1:16:05 PM
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> Create a new larger pds.  Use ISPF option 3.3 to copy any members... one
> at a time... as you can.  That should save some
> PRINT the data set and that may show you "some parts" of the missing
> members in a flat file
> Finally try to compress it.  Compress may save it... or totally destroy
> it.
> So, exactly WHY are you not backing this thing up ?  Naughty boy.
> 
> 
> 
> From:  esmie moo 
> To:    IBM-MAIN@bama.ua.edu
> Date:  07/26/2011 10:03 AM
> Subject:        CORRUPT PDS - I/O ERROR
> Sent by:        IBM Mainframe Discussion List 
> 
> 
> 
> Good Morning Gentle Readers,
> 
> When I try to browse a member of  my pds I get a I/O error.  I tried
> browsing several members but I get the same error message.  Is there a way
> of fixing it?  For some reason the storage group is NOT backed up so I
> cannot restore it from an old backup.  I recovered the PDS from a DFHSM
> backup but when I try to browse any members I still get the I/O error.  Is
> there a work around to this problem or should I consider it lost?
> 
> Thanks.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Re-entrant module stores into itself with no 0C4

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, July 19, 2011 5:46 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Re-entrant module stores into itself with no 0C4
> 
> On Tue, 19 Jul 2011 21:46:20 +, Gibney, Dave wrote:
> >> >>
> >>
> http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=/com.i
> bm.zos.r12.ieae200/progref.htm
> >> >
> >> >Actually, it not that I think it is no good, I think it's a long time 
> >> >coming.
> The
> >> problem is that I also know of at least one program (central to our batch
> >> processing) that exploits this "feature" :)
> >> >
> >> Relink it.
> >
> >I said exploits, not tolerates. By being marked RENT, the system still only
> loads one copy. Relink and I'll quickly use up virtual memory and suffer the
> overhead of loading multiple copies.
> >
> Since Ed J. has kindly reminded me of the difference, perhaps you
> should mark your module RENT,NOREFR (this shouldn't cause problems
> with REFRPROT, but perhaps Ed's experience is otherwise); and the OP
> mark his REFR and set REFRPROT=YES.

This is a reasonable suggestion and I may try it someday. Of course we started 
this path when I stated I know of one module we had which would be broken by 
setting REFPROT. I expect I would/will find others if/when I ever try REFPROT 
in our environment. So far, I still have products requiring key 8 user CSA, so 
REFPROT is further down on the list of things I may never get to :) because of 
the things higher on the list I might get to someday :(

Dave Gibney
Information Technology Services
Washington State University

> 
> In fact, many decades ago, a colleague did the experiment and
> confirmed what he inferred from the manual.  IIRC, REUS was
> sufficient to prevent loading multiple copies.  But the memory is
> fading, and perhaps things have changed.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Re-entrant module stores into itself with no 0C4

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, July 19, 2011 1:46 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Re-entrant module stores into itself with no 0C4
> 
> On Tue, 19 Jul 2011 20:16:26 +, Gibney, Dave wrote:>>
> >>
> >>
> http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=/com.i
> bm.zos.r12.ieae200/progref.htm
> >
> >Actually, it not that I think it is no good, I think it's a long time 
> >coming. The
> problem is that I also know of at least one program (central to our batch
> processing) that exploits this "feature" :)
> >
> Relink it.

I said exploits, not tolerates. By being marked RENT, the system still only 
loads one copy. Relink and I'll quickly use up virtual memory and suffer the 
overhead of loading multiple copies. 

It's what I understand to be a fairly classic technique of the time. If an 
address is zero, load the module containing the address and fill in the 
address, otherwise just branch. If the first module happened to be refreshed, 
well, I just get another copy, or find the called module and restore the 
address. Saves overhead of searching for the called module at every call.

Yes, I could rewrite it. And yes, the avoided overhead is probably less than it 
was when the module was designed and written in 1979, and yes such "trickeses" 
are more frowned upon today.

But, this module in the pathway of a substantial percentage of our calls to 
Adabas, hasn't even burped in a couple of decades and getting permission to 
change plus resources to test properly, just ain't gonna happen.

Which I guess make me a "resistant to change" z/OS Systems Programmer. :)

> 
> I'm biased.  In our ISV development shop, we must test in the most
> restrictive environments.  REFRPROT=YES; USERKEYCSA=NO, etc.
> If IBM would tell us about dirty GETMAIN, we'd use that, too.
> 
> >So although I think it's "better" that reentrant marked modules actually be
> reentrant and might have been inclined to enforce that had I had a say in the
> mythical man month days, I don't get to just turn this on and say sorry to my
> programmers and management.
> >
> Had the designers been thinking in those days, it would have been the
> standard; never an option.  Simply, a developer screwed up and put the
> test of the AC bit in the wrong code path.  It should never have been
> sensitive to the status of the library.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Re-entrant module stores into itself with no 0C4

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, July 19, 2011 12:55 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Re-entrant module stores into itself with no 0C4
> 
> On Tue, 19 Jul 2011 12:50:20 -0700, Skip Robinson wrote:
> 
> >RENT is honored--i.e. failed if violated--only if the load library is APF
> >authorized.
> >
> From:
> 
>   z/OS V1R12.0 MVS Initialization and Tuning Reference
> 
> 
> http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=/com.i
> bm.zos.r12.ieae200/progref.htm
> 
> Using the REFRPROT statement
> 
> z/OS V1R12.0 MVS Initialization and Tuning Reference
> SA22-7592-21
> 
> Use the REFRPROT statement type to specify that REFR programs are
> protected from modification by placing them in key 0, non-fetch protected
> storage, and page protecting the full pages. For more information on
> protection of REFR programs, see z/OS MVS Program Management: User's
> Guide and Reference.
> 
> |The handling that CONTENTS SUPERVISION provided for |REFR modules
> from APF-authorized libraries can be extended to non-APF |libraries if you
> set this value to REFRPROT. In other words, when |REFRPROT is in effect with
> MVS for APF libraries, they can be extended |to non-APF libraries as well.
> 
> Naturally, since it's new some z/OS programmers will think it's no good,
> or too much like UNIX or Windows or such.

Actually, it not that I think it is no good, I think it's a long time coming. 
The problem is that I also know of at least one program (central to our batch 
processing) that exploits this "feature" :) 

So although I think it's "better" that reentrant marked modules actually be 
reentrant and might have been inclined to enforce that had I had a say in the 
mythical man month days, I don't get to just turn this on and say sorry to my 
programmers and management.

Dave Gibney
Information Technology Services
Washington State University
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA-1 TMS QUESTION - IEFTMS9 TMC BACKUP REQUIRED

[Gibney, Dave]

More correct actions for something like this:

Look in the install/ongoing support sections of the documentation, find where 
it says you should run TMSCOPY on a regular basis and schedule such a job :) 
Make sure you do the other regular maintenance to the TMS that are documented 
in the same section of the manuals.

Add automation to act on the IEFTM99 message with an alert and a special run of 
the TMSCOPY job. 

If this was an out of the ordinary, greater than usual amount of tape activity, 
find out what happened and be sure it was valid,

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Mark Zelden
> Sent: Monday, July 18, 2011 12:13 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CA-1 TMS QUESTION - IEFTMS9 TMC BACKUP REQUIRED
> 
> On Mon, 18 Jul 2011 09:12:59 -0700, esmie moo 
> wrote:
> 
> >Good Morning Gentle Readers,
> >
> >I was called because the following message was coming up on the console:
> >IEFTMS9 TMC BACKUP REQUIRED, AUDIT FILE UTILISATION IS CURRENTLY
> 82%.
> >
> 
> 
> >What I would like to know if this is the correct action to take or should I 
> >have
> done something else.  Please advise.
> >
> >Thanks in advance.
> >
> >
> 
> Correct actions for something like this:
> 
> 1) Look up message IEFTMS9 from the CA manual and note the action
> 
> 2) If you don't understand #1, contact the vendor.
> 
> Your statement "should I have done..." implies you already did this, so it
> doesn't appear to
> be an 0 dark 30 question where you didn't understand the manual and didn't
> want to
> wait for a return call from the vendor.
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://expertanswercenter.techtarget.com/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Overriding client FTP . DATA

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Johnston, Robert E
> Sent: Tuesday, July 12, 2011 3:01 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Overriding client FTP . DATA
> 
> We started out years ago with CA's TCP/IP and FTP and it has remained the
> standard FTP in Production since then. A new project came up involving lots
> of new batch FTP jobs to a Windows machine and I suggested they use IBM
> FTP. It has gone well for the most part and the couple of problems
> encountered were fixed, but I'm not sure it was the "best" fix for the
> problems.
> 
> All production batch is submitted via CA-7 scheduler. The userid associated
> with all jobs submitted is "CA7". For some FTP from tape we had to add a
> SYSFTPD DD to batch jobs to add "AUTOTAPEMOUNT TRUE".
> 
> I have looked at FTP client search orders in the IP manuals for some kind of
> global FTP.DATA, but it is unclear to me the best way to handle this issue.
> Besides CA7, we have a few people that submit FTP batch jobs thru TSO. I
> would rather not have to add SYSFTPD DD statements.
> 
> Could I make a CA7.FTP.DATA and have all jobs submitted thru CA7
> automatically use this file? (I suppose TSO users would have
> tso_prefix.FTP.DATA when needed).

Most likely the answer is yes. userid.FTP.DATA is how we handle specific needs. 
But, if you look in the JESYSMSG of an FTP job, you will very likely find the 
dataset containing your default profile. Actually, this profile dsname is also 
listed in the messages from the FTP client session with a moderate level of 
logging turned on.


> 
> We don't have a SYS1.TCPPARMS(FTPDATA) or TCPIP.FTP.DATA. Is that the
> way to go?
> 
> I'm interesting in hearing how others handle their ftp.data for batch clients.
> Thanks for any information or advice.
> 
> Robert Johnston
> UAMS - Little Rock
> Confidentiality Notice: This e-mail message, including any attachments,
> is for the sole use of the intended recipient(s) and may contain
> confidential and privileged information.  Any unauthorized review,
> use, disclosure or distribution is prohibited.  If you are not the
> intended recipient, please contact the sender by reply
> e-mail and destroy all copies of the original message..
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Meet IBM's new $75,000 mainframe

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Ted MacNEIL
> Sent: Tuesday, July 12, 2011 12:13 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Meet IBM's new $75,000 mainframe
> 
> >They may be meaningless, but in reality, I have very little else to use
> 
> You're correct. You have very little else to use!
> 
> The figures are indefensible, unscientific, and what you're betting your
> business needs on.

And, they or something equally nebulous is what my software charges will be 
claimed to be based on. 

Dave Gibney
Information Technology Services
Washington State University> 
> Aside from that, Mrs Kennedy, what'd you think of Dallas?
> 
> (No disrespect intended)
> -
> Ted MacNEIL
> eamacn...@yahoo.ca
> Twitter: @TedMacNEIL
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Meet IBM's new $75,000 mainframe

[Gibney, Dave]

I thank Walt for the link, and confess to not thoroughly reading the 
announcement. They may be meaningless, but in reality, I have very little else 
to use as a starting point in comparing the z114 with my current z9BC-L03. 
Since I currently hardcap without serious impact at 16 MSU, it looks like a 
2818-F03 maybe the machine I should look at.

And, yes, I'll use zPCR and consult with our business partner(s). I have an 
uphill battle in promoting any change, since "the mainframe is leaving in 5 
years :("

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Ted MacNEIL
> Sent: Tuesday, July 12, 2011 11:25 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Meet IBM's new $75,000 mainframe
> 
> >MIPS or LSPR tables please?
> 
> Aside from the fact they're meaningless, the announcement does point that
> LSPR has already been updated at IBM's LSPR site.
> 
> -
> Ted MacNEIL
> eamacn...@yahoo.ca
> Twitter: @TedMacNEIL
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Meet IBM's new $75,000 mainframe

[Gibney, Dave]

MIPS or LSPR tables please?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Roach, Dennis (N-GHG CORP.)
> Sent: Tuesday, July 12, 2011 7:23 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Meet IBM's new $75,000 mainframe
> 
> New zEnterprise 114 is primarily competing against a Linux server running
> on an x86 platform, analyst says
> 
> 
> http://www.computerworld.com/s/article/9218326/Meet_IBM_s_new_75_000_mainf
> rame?source=CTWNLE_nlt_dailyam_2011-07-12
> 
> 
> Dennis Roach
> GHG Corporation
> Lockheed Martin Mission Services
> Facilities Design and Operations Contract
> Strategic Technical Engineering
> NASA/JSC
> Address:
>2100 Space Park Drive
>LM-15-4BH
>Houston, Texas 77058
> Mail:
>P.O. Box 58487
>Mail Code H4C
>Houston, Texas 77258-8487
> Phone:
>Voice:  (281)336-5027
>Cell:   (713)591-1059
>Fax:(281)336-5410
> E-Mail:  dennis.ro...@lmco.com
> 
> All opinions expressed by me are mine and may not agree with my employer
> or any person, company, or thing, living or dead, on or near this or any
> other planet, moon, asteroid, or other spatial object, natural or
> manufactured, since the beginning of time.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: End of of Ads thread

[Gibney, Dave]

Shai, one and only one individual  complained about you. Please ignore this 
individual whose contributions to this forum, IMO, are of marginal use anyway.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of shai hess
> Sent: Thursday, July 07, 2011 8:53 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: End of of Ads thread
> 
> HI,
> 
>  I like to stop this thread which last too long time.
>  I will not post anymore to IBM-MAIN about my product.
>  The last 2 posts target to keep my and my product good name.
>  I create a new Forum in my site. I hope it will works.
>  I really do not need forum because I like that people will use my
> product and ask questions directly to my email.
>  Any question will be sent to my user list.
>  Please do not mention MFNetDisk again.
>  Let the users deal with it if they like in my forum or my email.
> 
>  I thank God for everything and I know that everything is happen by God.
>  God helps me all the time and I am sure that also in this time.
>  Even if this event looked to me at first, bad.  I know the outcome
> will be good to me as always,because God beside me.
> 
>  Thanks,
>  Shai
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Lines, Bars and ... mini-bars???

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Rick Fochtman
> Sent: Tuesday, July 05, 2011 4:38 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Lines, Bars and ... mini-bars???
> 
> 
> 
> >>So I'm working on XDC adding support for debugging execution "above
> >>the bar", when I run into a nomenclature problem...
> >>
> >>"Above the line" means >16M.
> >>"Above the bar"  means >4G.
> >>
> >>But AMODE(31) supports execution in only the zero to 2G range. For
> >>the 2G to 4G range, you need AMODE(64).
> >>
> >>So what is the name for the 2G to 4G range of storage? . . .
> >>
> >>

I've never had a problem considering it "within the bar". I always thought of 
the "bar" as being 2G thick as opposed to the 2 dimensional "line". High School 
geometry concept :)

Dave Gibney
Information Technology Services
Washington State University

> >
> >"Black hole".
> >
> >
> ---
> Let's call it a "zero-gravity black hole", since it doesn't seem to
> attract anything except questions.  :-)
> 
> Rick
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Empty output in netstat home z/OS 1.10

[Gibney, Dave]

Chris is likely correct. I would suspect you did not properly clone or 
otherwise upgrade your Unix System Services root when you moved to z/OS 1.10

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Chris Mason
> Sent: Friday, July 01, 2011 7:46 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Empty output in netstat home z/OS 1.10
> 
> Jorge
> 
> > Last Saturday we've upgrade our production lpar to z/OS 1.10.
> 
> I believe you have a problem accessing the templates used to define the
> fixed
> content of messages.
> 
> You should review your installation steps in order to work out something not
> done or not done correctly.
> 
> I have no experience of the installation steps so you will need to take it 
> from
> here - or perhaps someone who recognises the problem can jump in with
> more
> details.
> 
> In any case, your best bet for expertise with the IP component of z/OS
> Communications Server - as you may have noticed I tirelessly point out - is
> the following list:
> 
> For IBMTCP-L subscribe / signoff / archive access instructions, send email to
> lists...@vm.marist.edu with the message: INFO IBMTCP-L
> 
> Chris Mason
> 
> On Fri, 1 Jul 2011 07:07:10 -0500, Jorge Garcia 
> wrote:
> 
> >Hello:
> >
> > Last Saturday we've upgrade our production lpar to z/OS 1.10. Since last
> >saturday when we enter the netstat home command we received this
> output:
> >
> > ...
> >
> >Jorge García Juanino
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSP buckets for a z10 mainframe

[Gibney, Dave]

>From wait 064
009 A program check occurred. Accompanying message IEA304W further explains 
this wait state and entry code. If the message does not appear on the console, 
you can find the message in the wait state message area (WSMA). The WSMA is 
described in the z/OS Internet Library at 
http://www.ibm.com/systems/z/os/zos/bkserv/ for z/OS MVS Data Areas manuals.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of John Norgauer
> Sent: Thursday, June 30, 2011 2:57 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PSP buckets for a z10 mainframe
> 
> We had a system wait state code of 9064.
> 
> 
> 
> John Norgauer
> Senior Systems Programmer
> Mainframe Technical Support Services
> University of California Davis Medical Center
> 2315 Stockton Blvd
> ASB 1300
> Sacramento, Ca 95817
> 916-734-0536
> 
>  SYSTEMS PROGRAMMING..  Guilty, until proven innocent !! "JN  2004
> 
> "Hardware eventually breaks - Software eventually works"  anon
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSP buckets for a z10 mainframe

[Gibney, Dave]

No.

By "would not IPL", what do you really mean. As in what is the wait state code, 
or error messages on the console?

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of John Norgauer
> Sent: Thursday, June 30, 2011 2:48 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: PSP buckets for a z10 mainframe
> 
> We are still running z/OS 1.9 and are getting a z10 frame. Aftter applying
> the PSP PTF's recommended for 1.9, My 1.9 system would not IPL.
> 
> Could it be that the PSP PTF's when applied, need to be IPL'ed on a z10?
> 
> 
> 
> John Norgauer
> Senior Systems Programmer
> Mainframe Technical Support Services
> University of California Davis Medical Center
> 2315 Stockton Blvd
> ASB 1300
> Sacramento, Ca 95817
> 916-734-0536
> 
>  SYSTEMS PROGRAMMING..  Guilty, until proven innocent !! "JN  2004
> 
> "Hardware eventually breaks - Software eventually works"  anon
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Link edit failure while applying PTF

[Gibney, Dave]

Look in the SYSPRINT of the job for the specific link edit errors

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of sourabh khandelwal
> Sent: Monday, June 27, 2011 9:30 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Link edit failure while applying PTF
> 
> Hello,
>   While applying RSU on z/OS 1.9 system, I have encountered
> below
> error with link edit processing failed.
> 
> GIM23911E ** LINK-EDIT PROCESSING FOR SYSMOD UA51212 FAILED FOR MODULE
> CSFMCCCP
>  IN LMOD CSFMMAIN IN THE SCSFMOD0 LIBRARY. THE RETURN CODE
> (12)
>  EXCEEDED THE ALLOWABLE VALUE. DATE 11.173 - TIME 10:27:23
> -
>  SEQUENCE NUMBER 000220 - SYSPRINT FILE SMP00069.
> GIM23911E ** LINK-EDIT PROCESSING FOR SYSMOD UA51253 FAILED FOR MODULE
> CSFMTDSL
>  IN LMOD CSFMMAIN IN THE SCSFMOD0 LIBRARY. THE RETURN CODE
> (12)
>  EXCEEDED THE ALLOWABLE VALUE. DATE 11.173 - TIME 10:27:23
> -
>  SEQUENCE NUMBER 000220 - SYSPRINT FILE SMP00069.
> GIM23911E ** LINK-EDIT PROCESSING FOR SYSMOD UA51253 FAILED FOR MODULE
> CSFMTXCF
>  IN LMOD CSFMMAIN IN THE SCSFMOD0 LIBRARY. THE RETURN CODE
> (12)
>  EXCEEDED THE ALLOWABLE VALUE. DATE 11.173 - TIME 10:27:23
> -
>  SEQUENCE NUMBER 000220 - SYSPRINT FILE SMP00069.
> GIM23911E ** LINK-EDIT PROCESSING FOR SYSMOD UA90554 FAILED FOR MODULE
> CSFCS001
>  IN LMOD CSFMMAIN IN THE SCSFMOD0 LIBRARY. THE RETURN CODE
> (12)
> 
> 
> I tried to look at google to find solution for this problem, but some
> of the
> link only tells about to have PDSE type dataset.
> 
> Can you please help me to resolve this issue.
> 
> --
> Thanks & Regards
> Saurabh Khandelwal
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SDSF question

[Gibney, Dave]

Yep, it's active. On the DA panel, it is a running task not in a wait.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Roger Bolan
> Sent: Saturday, June 25, 2011 1:13 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SDSF question
> 
> I see this on output queues when the job is selected for an active
> printer.
> Is that what you mean?
> On Jun 25, 2011 11:41 AM, "Phil Smith III"  wrote:
> > When I'm looking at a queue in SDSF, what does it mean when a job
> output
> is
> > highlighted? It seems almost random, but I'm sure it isn't!
> >
> >
> >
> >
> >
> >
> > -
> -
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html