Re: System programmer position in Montreal, QC

[Ted MacNEIL]

>Give them a call Ted 

I considered it, but I'm more of a Capacity/Performance/Configuration type than 
a SYSPROG.

I haven't written in assembler since the early 1980's and haven't used SMP 
since before it was called SMP/E.

-
Too busy driving to stop for gas!

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

SMF type 30 record question.

[McKown, John]

has anybody seen a single logical type 30 record which has been "split"
into multiple physical type 30 records? Is such a logical record
guaranteed to have its "segments" physically contiguous? Or could a
different SMF record be written in the middle of such a logical type 30?
I'm trying to figure out how to process such a thing short of loading
the information into a database and extracting it later. I am also
worried that the "first segment" could be written to one MANx dataset
and that record causes SMF to switch to another MAN dataset. In our
processing, this would result in the two segments being in different
sequential, GDG files. Because we do GDG-all processing to combine these
GDGs daily, the segments could be out-of-order in a physical sense. And
separated by quite a number of other records.

Any words of wisdom? Is there some SORT that I could do which would
guarantee that the "split" type 30s would be in order after the sort?

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

Re: linklisted load library failing

[Ted MacNEIL]

>I'm pretty sure that limit is 123 extents.  It may have been changed in a 
later release though.

255 extents; just like the JCL concatenation limit.
If your datasets are all in one extent you can get to 255 datasets.
BTW, a PDSE counts as only one extent, regardless.

-
Too busy driving to stop for gas!

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

Re: Shooting of Commands

[Vernooy, C.P. - SPLXM]

"Gaur" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Does anyone know how to shoot commands at particular time or on coming
> of particular message in log.My intention is to start a started tasks
> or jobs which do specific function However the Lpar where I want this
> to be done is having none of the product for Automation or
Scheduling..
> 

You do have 1 tool to issue commands at specific times: JES2 automatic
commands. 
Check the $TA command.

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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ICKDSF Intilize question.

[Howard Rifkind]

Rex, no, all I want to do is change the volser on this
volume.

Reason.  A long time ago some genius here decided to
have volumes on both the test and prod volume the
same.  Go Figure!
--- "Pommier, Rex R." <[EMAIL PROTECTED]>
wrote:

> Howard, 
> 
> What are you trying to do?  The REFORMAT command
> David sent will change
> the VOLSER.  If you want to rename a dataset or
> somehow change some
> other information you will need to use AMASPZAP
> instead of ICKDSF.  But
> that being said, there are other steps/gyrations you
> need to go through
> to make sure you don't mess the volume up.  Give us
> some more
> information as to what specifically you're wanting
> to do.
> 
> Rex 
> 
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Howard Rifkind
> Sent: Tuesday, August 14, 2007 2:22 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: ICKDSF Intilize question.
> 
> I know there is a way to zap the VTOC on a volume
> without destroying the
> data.  
> 
> I tried to find my JCL to do this...can't.
> 
> Any help with the ICKDSF control statement would be
> greatly appreciated.
> 
> Thanks.
> 
>
--
> For IBM-MAIN subscribe / signoff / archive access
> instructions,
> send email to [EMAIL PROTECTED] with the message:
> GET IBM-MAIN INFO
> Search the archives at
> http://bama.ua.edu/archives/ibm-main.html
> 



   

Be a better Heartthrob. Get better relationship answers from someone who knows. 
Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

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

Re: ICKDSF Intilize question.

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

OK, so you want to change the volser. How are you going to reset the catalog 
pointers?
 
I also worked at a shop with multiple LPARs with sets of volsers that were the 
same on each LPAR. Their reasoning was that it allowed for an easy refresh of 
the test LPARs.



From: Howard Rifkind [mailto:[EMAIL PROTECTED]
Sent: Tue 8/14/2007 6:15 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: ICKDSF Intilize question.



Rex, no, all I want to do is change the volser on this
volume.

Reason.  A long time ago some genius here decided to
have volumes on both the test and prod volume the
same.  Go Figure!



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

Re: Outsourcing loosing steam?

[Howard Brazee]

On 14 Aug 2007 13:03:19 -0700, [EMAIL PROTECTED] (Thompson,
Steve) wrote:

>However, let me just inject here, I am a pilot. I know that all the
>drivel coming from the airlines (and the ATA, their association) is
>bunk. The rules of physics will not be denied -- a runway can only
>handle so many aircraft per hour. Schedule twice that number, and you
>will inject delays.

I was a USAF pilot - but this law of traffic can be seen on highways,
golf courses...

and in computers, networks, programming...

We need to have gaps in the traffic if we don't want gridlock.

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

Re: Outsourcing loosing steam?

[CICS Guy]

Never the less, the LAX problem was reported as customs not being able to 
verify anybody because the computer was down...International flights 
only.


_
Tease your brain--play Clink! Win cool prizes! 
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2


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

Re: Tech Notes - Any body know about them or where they are hidden?

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Aaron Walker
Sent: Tuesday, August 14, 2007 9:54 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Tech Notes - Any body know about them or where they are
hidden?

Yes, it is not terribly well organized.



B I N G O 

If the communications server people had not told me where their tech
notes are, I would have never found them. And if you don't know the
number (ID) of the tech note, good luck searching IBM's web pages for
what you are looking for.

And so I put this question out to see if anyone else knew how to get to
these doc updates/corrections.

My argument to IBM's web page handlers is, these things are needed just
like the old TNLs we used to get. Only now that everything is committed
to CDs or DVDs, we really need a single place to go to for erratum.

Regards,
Steve Thompson

Opinions expressed are my own.

This e-mail message is intended only for the
addressee(s) and contains information that may be
confidential and/or privileged material. 
If you are not the intended recipient please notify
the sender by reply e-mail immediately.  
Use, disclosure or reproduction of any information
in this e-mail by anyone other than the intended
recipient(s) is strictly prohibited. 
Sterling Commerce is not liable for any loss or
damage arising in any way from transmission of
the message or use of its attachments.  
This email may contain links to third party web
sites. 
Sterling Commerce is not responsible for the
content or privacy policies of such other sites and
the existence of a link in this email does not imply
an endorsement of the linked web site or the goods
or services offered therein.

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

Re: Shooting of Commands

[Paul Gilmartin]

On Wed, 15 Aug 2007 11:10:17 +0200, Vernooy, C.P. - SPLXM wrote:

>"Gaur" wrote in message
>news:<[EMAIL PROTECTED]>...
>> Does anyone know how to shoot commands at particular time or on coming
>> of particular message in log.My intention is to start a started tasks
>> or jobs which do specific function However the Lpar where I want this
>> to be done is having none of the product for Automation or
>Scheduling..
>
>You do have 1 tool to issue commands at specific times: JES2 automatic
>commands.
>Check the $TA command.
>
Also crontab, though it would be pretty roundabout to issue an operator
command.

-- gil

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

Re: linklisted load library failing

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bill Wilkie
Sent: Tuesday, August 14, 2007 7:19 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: linklisted load library failing

You may also want to check on the Blksize of the libraries and place the
larger one first if they are different.


That particular restriction or issue was removed LONG ago.

However, I have been reading the posts on this, and I think you may want
to review all files in the LNKLST and ensure that that they are
allocated as only PRIMARY space.

I say this because I ran into a similar problem many years ago. The
library that was implicated as being bad (and that vendor's code) was a
victim. The immediately preceding PDS had gone to an extra extent (all
of 1 track). I can't recall the goofy reason why it happened, but it
wasn't until some rarely used function was used that we realized that
the cause was that PDS had expanded by 1 track during the life of that
IPL...

We tried refreshing LLA, VLF, etc., but until you dropped the whole
linklist and picked up a new one (or IPLed), you were going to have
problems.

And so, this is why I tell people to do their allocations for LNKLST or
CICS as only a primary, no secondary, CONTIG. And make the primary space
at least 25% larger than the used space once it is compressed
(especially so CICS).

Regards,
Steve Thompson
This e-mail message is intended only for the
addressee(s) and contains information that may be
confidential and/or privileged material. 
If you are not the intended recipient please notify
the sender by reply e-mail immediately.  
Use, disclosure or reproduction of any information
in this e-mail by anyone other than the intended
recipient(s) is strictly prohibited. 
Sterling Commerce is not liable for any loss or
damage arising in any way from transmission of
the message or use of its attachments.  
This email may contain links to third party web
sites. 
Sterling Commerce is not responsible for the
content or privacy policies of such other sites and
the existence of a link in this email does not imply
an endorsement of the linked web site or the goods
or services offered therein.

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

WTOREPLY Sample

[George Dranes]

I'm wondering if someone could point me to a sample source program for 
WTOREPLY.  I use it in our MPFLSTXX member to issue startup commands for 
TCPIP and TSO after VTAM has initialized.  I have the load module but can't 
find any source.  Thanks for the help.

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

Re: Shooting of Commands

[Jack Kelly]

You can always code an MPF exit and perform an action on a particular
message. Pretty easy to do. The exit is pretty well documented in MVS
Installation Exits manual



Jack Kelly
LA Systems @ US Courts
x 202-502-2390

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

Re: Shooting of Commands

[Matthew Stitt]

You have the IEAVMXIT console address space exit program available, and also
the MPF system available.  These exits could fire based on message numbers,
and/or words that you find in the syslog entries.  Also the free TSSO
subsystem and the free command scheduler system located on the CBT tape
could work for your purpose.

On Wed, 15 Aug 2007 11:10:17 +0200, Vernooy, C.P. - SPLXM
<[EMAIL PROTECTED]> wrote:

>"Gaur" <[EMAIL PROTECTED]> wrote in message
>news:<[EMAIL PROTECTED]>...
>> Does anyone know how to shoot commands at particular time or on coming
>> of particular message in log.My intention is to start a started tasks
>> or jobs which do specific function However the Lpar where I want this
>> to be done is having none of the product for Automation or
>Scheduling..
>>
>
>You do have 1 tool to issue commands at specific times: JES2 automatic
>commands.
>Check the $TA command.
>
>Kees.

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

Re: SMF type 30 record question.

[David Andrews]

On Tue, 2007-08-14 at 15:43 -0500, McKown, John wrote:
> has anybody seen a single logical type 30 record which has been "split"
> into multiple physical type 30 records?

Yes.  We have a few (big) jobs that cause this.

> Is such a logical record
> guaranteed to have its "segments" physically contiguous?

I'd very much doubt that.

> I am also worried that the "first segment" could be written to one
> MANx dataset and that record causes SMF to switch to another MAN
> dataset.

Ouch.  Good catch.

> Any words of wisdom? Is there some SORT that I could do which would
> guarantee that the "split" type 30s would be in order after the sort?

I don't think they have to be in order, 'cause they aren't segments in
the traditional sense.  Each record can stand alone, and contains
complete sections.

-- 
David Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]

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

encrypted 3172 and 3174 controller replacement

[Jack Kelly]

Has anyone experience with SecureAgent IDG 9074 ? It's a surprising
afforadable encrypted 3172 and 3174 controller replacement and seems to
deliver on the marketing hype. I'm interested in any comparable products/
TIA



Jack Kelly
LA Systems @ US Courts
x 202-502-2390

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

z/OS 1.6 PTF for 32 CPs per LPAR

[Bielskie, Stephen]

Does anyone know what z/OS 1.6 PTF changes the maximum number of CPs per LPAR 
from 24 to 32?  I have done multiple searches and found that one supposedly 
exists, but I can not find the exact PTF number.

Thanks in advance,
Steve

Stephen Bielskie
Assistant Vice President
IT -  z/OS Base Products - Princeton
KIUT 57

CREDIT  SUISSE  

Princeton, NJ  
Telephone : (609) 243-0711 
Email :[EMAIL PROTECTED]




==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

Re: SMF type 30 record question.

[Barry Merrill]

Type 30 records are frequently "split" when there are more DD segments
that can fit in a physical SMF record, known as MULTIDD='Y'
to MXG users, and there most defintely can be other SMF records
between the multiple phyical 30 records, as it takes finite
time to create each of the MULTIDD records.

You can detect this is the first, middle, or last of a 
series of split records by the count fields (for DD
segments, SMF30EON/EOR/EOS).

It's also possible to have an SMF 30 record split for
reasons other than too many DD's: an abundance of OMVS
segments and/or MULC, APPC, or ARM segments can also
split a logical SMF 30 into multiple, separately written,
physical SMF 30 records.

Barry Merrill 

P.S. Of course, the holding of a partial record from today's SMF file
 until tomorrow's processing, after detection of an incomplete
 SMF 30 logical record, requires additional logic, provided in
 MXG's case by its "SPIN" logic to hold incomplete jobs.

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

Re: encrypted 3172 and 3174 controller replacement

[Jim Wangler]

We've had an IDG 9074 for a couple of years now and have not had any
problems with it  


Jim Wangler 
214-502-6445

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

Attachmate

[Grant Ward Able]

Does anyone know how to setup a quickpad in Attachmate for TSO-ISPF, to 
send the PA1 key ?

-- 
Regards - Grant




DTCC DISCLAIMER: 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. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.

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

Re: linklisted load library failing

[Peter Relson]

No one appeared even to take the step of inquiring what caused the 0C1 or
0C4.

It is very unlikely that extents have anything to do with this, as an
extent problem would usually result in some sort of fetch failure, well
preceding a module execution problem.. It is possible that reentrancy has
something to do with this.

I would start by getting a dump of the failure. And seeing if the module
that is in storage is actually what you think it is (and possibly compare
that to a similar dump (if you can get one) when it works. Then see what
caused the abend.

If it was just an 0C4 then reentrancy and the key of the program storage
seems quite possibly to be involved. The dump should show you in what key
the module was placed.

PIC 1's are usually pretty easy to see too. Is the instruction address in
your module (and was the program storage overlaid)? If running on a z9, the
breaking event address might help determining where you branched from.

Peter Relson
z/OS Core Technology Design

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

GDG question

[Hare, Tim]

I need to move some existing GDG datasets from tape to disk.  Normally, I would 
create a new version of each generation (V00 to V01, etc.), however these are 
created by a product which records the dataset name when they are created, and 
uses the actual name (whatever.G0001V00) when referencing the dataset. I 
therefore have to end up with the same names.

I can uncatalog the old dataset, and create the new dataset, in the same job; 
or I could create a new version, then later rename it. My main question is 
whether I need to do this in a specific order to avoid losing the oldest 
generation that exists?

Tim Hare
Senior Systems Programmer
Florida Department of Transportation
Tel: +1 (850) 414-4209

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Grant Ward Able
Sent: Wednesday, August 15, 2007 10:55 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Attachmate

Does anyone know how to setup a quickpad in Attachmate for TSO-ISPF, to
send the PA1 key ?

--
Regards - Grant




DTCC DISCLAIMER: 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. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Outsourcing loosing steam?

[daver++]

> From: CICS Guy <[EMAIL PROTECTED]>
> 
> Never the less, the LAX problem was reported as customs not being able to 
> verify anybody because the computer was down...International flights 
> only.

"Around 1:30 p.m., the CPB experienced problems accessing its database
containing information on international travelers. Assuming this to be a
wide-area network problem, CBP called Sprint, its carrier, to test the
lines. After three fruitless hours of remote testing, Sprint finally
sent technicians on-site. Another three hours passed before Sprint
finally concluded that transmission lines were not the problem, meaning
the problem was inside the CBP local network. After more hours of
troubleshooting, the issue was finally resolved at 11:45 p.m. The real
culprit: a failed router."
http://blogs.zdnet.com/projectfailures/?p=346

20,000 stranded because it took over ten hours to diagnose and replace a
failed router. I used to be a mainframe guy that inherited the network
side, so they cut me some slack. BUT- I can guarantee that there wasn't
anywhere near enough slack for me to get off with taking that long to
replace a router. I would have been tarred, feathered and run out of
town. It seems like basic due diligence wasn't even followed. Yes,
Sprint added to the problem, but Sprint never should have been called.
Why call Sprint before determining that the problem isn't on _your_ end?
It is all a bit silly, and it frightens me a bit that our airlines have
this level of quality.

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

Unerase utility

[Bob]

Hi all

I don't think anything like this exists... but we had an inadvertant deletion 
of a 
PDS dataset cat'd in the mastercat, on a test system - not a backed up pack.

The pack had not been touched, no updates to the MCAT since the typo.

Can anyone recommened a util that can recover the data in a reasonable 
manner ? 

(I DIDN'T DO IT) 

Thanks in advance!

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

Re: ICKDSF Intilize question.

[Pommier, Rex R.]

 Howard,

Then the REFORMAT in ICKDSF will change a VOLSER without disrupting any
data on the volume.  But as David pointed out, relabeling the VOLSER
will definitely break all your catalog pointers to data on that volume.
In addition, although I don't know if this will actually break anything
or just be a cosmetic thing, but the VVDS and/or VTOCIX datasets will
not be renamed to reflect the new volser.  

Rex



From: Howard Rifkind [mailto:[EMAIL PROTECTED]
Sent: Tue 8/14/2007 6:15 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: ICKDSF Intilize question.



Rex, no, all I want to do is change the volser on this volume.

Reason.  A long time ago some genius here decided to have volumes on
both the test and prod volume the same.  Go Figure!

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

Re: Outsourcing loosing steam?

[Hare, Tim]

I wonder if the LAX tech support is contracted out to some company, not done by 
employees? Of course even employees assume that it isn't them  we get a lot 
of service desk calls sent to us for 'mainframe is down' when the problem is 
that their local network guys unplugged something in the path to us, or 
filtered out something necessary to communications with us, because they didn't 
understand its purpose. Instead of looking at local changes first, they assume 
of course that a statewide resource, which has a sterling record of up time, 
has been allowed to fail in the middle of prime time!

Tim Hare
Senior Systems Programmer
Florida Department of Transportation
Tel: +1 (850) 414-4209

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

Re: linklisted load library failing

[Mark Zelden]

On Tue, 14 Aug 2007 21:41:02 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote:

>>I'm pretty sure that limit is 123 extents.  It may have been changed in a
>later release though.
>
>255 extents; just like the JCL concatenation limit.

True now, but this did change much more recently than the LNKLST 
change from DFSMS 1.3.  The old limit used a formula similar to the old
LNKLST limit where the result of the formula couldn't exceed 2040.

The change to allow 255 extents was in z/OS DFSMS 1.5 (z/OS 1.5). 

>If your datasets are all in one extent you can get to 255 datasets.
>BTW, a PDSE counts as only one extent, regardless.
>

Unix directories also count as one towards the 255 extent limit. 

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: Unerase utility

[John P Kalinich]

Bob Hensel of the IBM Mainframe Discussion List 
wrote on 08/15/2007 10:23:06 AM:

> Hi all
>
> I don't think anything like this exists... but we had an inadvertant
> deletion of a
> PDS dataset cat'd in the mastercat, on a test system - not a backed up
pack.
>
> The pack had not been touched, no updates to the MCAT since the typo.
>
> Can anyone recommened a util that can recover the data in a reasonable
> manner ?
>

This was recently discussed here in detail.  Check the archives at
http://bama.ua.edu/archives/ibm-main.html.

Regards,
John K

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

Re: linklisted load library failing

[Mark Zelden]

On Wed, 15 Aug 2007 09:29:51 -0400, Thompson, Steve
<[EMAIL PROTECTED]> wrote:
>
>However, I have been reading the posts on this, and I think you may want
>to review all files in the LNKLST and ensure that that they are
>allocated as only PRIMARY space.
>
>I say this because I ran into a similar problem many years ago. 

Completely different problem.  Your problem would lead to fetch
abends (106-0F).  Not 0C1/0C4.   The OP (or someone) needs to look at a 
dump.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

SHARE Snubbery Report

[John P Kalinich]

Who has the most snubs so far?

Regards,
John K

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

Re: Attachmate

[Gary Threadgold]

[EMAIL PROTECTED], on 2007-08-15 at 16:54, wrote:
>Does anyone know how to setup a quickpad in Attachmate for TSO-ISPF, to 
>send the PA1 key ?
>
>-- 
>Regards - Grant

Hi Grant,
>From within an Extra session, click on Option -> Settings, then select 
>QuickPads.  You'll then need to edit an existing one or create a new one; 
>either way, create a new button (using the button icon available in the 
>toolbar).  Double-click your newly-created button and then select the "Action" 
>tab from the subsequent page.  Choose the "Miscellaneous" category and the 
>"Send Keys" command.  Some further options should then appear on the right.  
>Under "Display Keys", select "PA1" and then click on "Add to Keystrokes".  
>Follow all of this up with a random combination of "OK", "Save", etc., and you 
>should find that you have a working QuickPad.

Regards,
Gary.
UNHCR, Geneva, Switzerland.

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

Re: linklisted load library failing

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Wednesday, August 15, 2007 10:30 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: linklisted load library failing

On Wed, 15 Aug 2007 09:29:51 -0400, Thompson, Steve
<[EMAIL PROTECTED]> wrote:
>
>However, I have been reading the posts on this, and I think you may 
>want to review all files in the LNKLST and ensure that that they are 
>allocated as only PRIMARY space.
>
>I say this because I ran into a similar problem many years ago. 

Completely different problem.  Your problem would lead to fetch
abends (106-0F).  Not 0C1/0C4.   The OP (or someone) needs to look at a 
dump.


Normally, true. And we were also getting those type abends as well. 

But in our case (this happened on a P/390, running MVS 5.2.2), we did
get some rather interesting abends, where in looking at the module in
memory, we could see that something wasn't right. The solution, in that
case, was as I stated.

And it was a real head-scratcher.

Regards,
Steve Thompson
This e-mail message is intended only for the
addressee(s) and contains information that may be
confidential and/or privileged material. 
If you are not the intended recipient please notify
the sender by reply e-mail immediately.  
Use, disclosure or reproduction of any information
in this e-mail by anyone other than the intended
recipient(s) is strictly prohibited. 
Sterling Commerce is not liable for any loss or
damage arising in any way from transmission of
the message or use of its attachments.  
This email may contain links to third party web
sites. 
Sterling Commerce is not responsible for the
content or privacy policies of such other sites and
the existence of a link in this email does not imply
an endorsement of the linked web site or the goods
or services offered therein.

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

Weird COBOL issue

[Todd Burrell]

All:
We have a strange COBOL issue occurring, and I cannot remember what is 
causing this.  Starting a few days ago, when our programmers compile a cobol 
program and try to run it, their print files that should be 133 characters in 
length (RECFM=FBA) are failing with basically the old S001 abend, but in this 
case it is the message IGZ0201W about the record length mismatch, and then 
the job abends with a U4038 with additional message IGZ0035S indicating the 
file status 39 error. 

They can get the job to run by changing the LRECL to 134 instead of 133, and 
when I compare the current 134 length file with the old production run from 
last week that worked (LRECL 133) the only difference I see is an extra 
characer inserted before the first character of the record.  So the old record 
looks like this (PRINT CONTROL CHARACTER INCLUDED):

1REPORT HEADER 

The new one where I had to make the LRECL 134 to avoid the abend looks like 
this:

1 REPORT HEADER 

Does anyone know what can cause this (compiler option or PTF)?  I seem to 
remember this happening a long time ago, but I have long forgotten what 
caused this, and how I fixed it.  

We are currently z/OS 1.8, and have been for about 7 weeks, and this issue 
started around a week ago.  So I don't think it's an upgrade issue. 

Thanks 

Todd Burrell

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

Re: SMF type 30 record question.

[Rick Fochtman]

---


has anybody seen a single logical type 30 record which has been "split" into multiple physical type 
30 records? Is such a logical record guaranteed to have its "segments" physically contiguous? Or 
could a different SMF record be written in the middle of such a logical type 30? I'm trying to figure out how 
to process such a thing short of loading the information into a database and extracting it later. I am also 
worried that the "first segment" could be written to one MANx dataset and that record causes SMF to 
switch to another MAN dataset. In our processing, this would result in the two segments being in different 
sequential, GDG files. Because we do GDG-all processing to combine these GDGs daily, the segments could be 
out-of-order in a physical sense. And separated by quite a number of other records.

Any words of wisdom? Is there some SORT that I could do which would guarantee that the 
"split" type 30s would be in order after the sort?
 



John, when we processed SMF, the processing program(s) were such that 
the order of the segments was not significant.


Our processing used a pair of CLISTS that did this:

1. List the cataloged GDG datasets.
2. Sort the contents of each dataset based on joblog information
3. Create SORTINxx DD statements for each of the datasets, along with 
the other DD statements, etc. for a MERGE.

4. Submit the MERGE job, merging all the GDG members to tape.

Our job scheduler was set to trigger on completion of the MERGE job and 
submit the remainder of our SMF processing.


We used a Automatic Command in JES2 to do a "I SMF" command on each 
image at midnight; IEFU29 exit caught the switch and submitted 
processing based on time-of-day (midnight to half-hour past midnight 
dictated daily processing; any other time submitted just a basic SMF dump.)


If I can find any of this stuff, I'll share it with you offlist.

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

Re: Outsourcing loosing steam?

[Chris Mason]

"Come back SNA, all is forgiven!"

Chris Mason

- Original Message - 
From: "daver++" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Wednesday, August 15, 2007 5:11 PM
Subject: Re: Outsourcing loosing steam?



From: CICS Guy <[EMAIL PROTECTED]>

Never the less, the LAX problem was reported as customs not being able to
verify anybody because the computer was down...International flights
only.


"Around 1:30 p.m., the CPB experienced problems accessing its database
containing information on international travelers. Assuming this to be a
wide-area network problem, CBP called Sprint, its carrier, to test the
lines. After three fruitless hours of remote testing, Sprint finally
sent technicians on-site. Another three hours passed before Sprint
finally concluded that transmission lines were not the problem, meaning
the problem was inside the CBP local network. After more hours of
troubleshooting, the issue was finally resolved at 11:45 p.m. The real
culprit: a failed router."
http://blogs.zdnet.com/projectfailures/?p=346

20,000 stranded because it took over ten hours to diagnose and replace a
failed router. I used to be a mainframe guy that inherited the network
side, so they cut me some slack. BUT- I can guarantee that there wasn't
anywhere near enough slack for me to get off with taking that long to
replace a router. I would have been tarred, feathered and run out of
town. It seems like basic due diligence wasn't even followed. Yes,
Sprint added to the problem, but Sprint never should have been called.
Why call Sprint before determining that the problem isn't on _your_ end?
It is all a bit silly, and it frightens me a bit that our airlines have
this level of quality.


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

Re: OSA-Express2 and SNA Pcomm - loss of connectivity

[Sheila Weissborn]

I want to clarify something so there is no misunderstanding.  I do not mean to 
imply that this is a problem with Cisco's equipment or any other component for 
that matter.  

The OSAs are connected to a Cisco 6500 switch which in turn connects to a 
core router.

Here are sample definitions in VTAM for the XCA member and the switched PU 
definition:
XCA04B00 VBUILD TYPE=XCA   
OSAFENT1 PORT  MEDIUM=CSMACD,  
   ADAPNO=0,   
   CUADDR=0B00,
   SAPADDR=04  
*  
GROUP1   GROUP ISTATUS=ACTIVE, 
   DIAL=YES,   
   CALL=IN,
   AUTOGEN=(2000,OSAL,OSAP)

VBUILD MAXGRP=1,MAXNO=1,TYPE=SWNET 
PUTECH0  PUADDR=50,IDBLK=05D,IDNUM=0,  
   DISCNT=NO,NETID=(,NOXNETLS),
   ANS=CONT,   
   IRETRY=YES, 
   PUTYPE=2,   
   MAXDATA=1033,   
   MAXOUT=7,   
   MODETAB=MODETBL,DLOGMOD=T3278M2,
   USSTAB=USSSNAT, 
   SSCPFM=USSSCS,  
   PACING=0,   
   VPACING=10, 
   MAXPATH=4,CPNAME=LUTECH00   
LUTECH00 LU   LOCADDR=00,DLOGMOD=IBMRDB,RESSCB=10 
LUTECH02 LU  LOCADDR=02,DLOGMOD=IMWKLU62,SSCPFM=FSS,ENCR=OPT
LUTECH03 LU  LOCADDR=03,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH04 LU   LOCADDR=04,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH05 LU  LOCADDR=05,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH06 LU   LOCADDR=06,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH07 LULOCADDR=07,DLOGMOD=T3278M2,
 SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH08 LULOCADDR=08,DLOGMOD=T3278M2,
 SSCPFM=USSSCS,USSTAB=USSSNAT

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

Re: Weird COBOL issue

[Greg Shirey]

Could you have gone from ADV=NO to ADV=YES on the COBOL compile option? 

See:
http://publib.boulder.ibm.com/infocenter/pdthelp/v1r1/index.jsp?topic=/c
om.ibm.entcobol4.doc/igyc1plc.htm

HTH,
Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Todd Burrell
Sent: Wednesday, August 15, 2007 11:10 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Weird COBOL issue


All:
We have a strange COBOL issue occurring, and I cannot remember what is 
causing this.  Starting a few days ago, when our programmers compile a
cobol 
program and try to run it, their print files that should be 133
characters in 
length (RECFM=FBA) are failing with basically the old S001 abend, but in
this 
case it is the message IGZ0201W about the record length mismatch, and
then 
the job abends with a U4038 with additional message IGZ0035S indicating
the 
file status 39 error. 

They can get the job to run by changing the LRECL to 134 instead of 133,
and 
when I compare the current 134 length file with the old production run
from 
last week that worked (LRECL 133) the only difference I see is an extra 
characer inserted before the first character of the record.  So the old
record 
looks like this (PRINT CONTROL CHARACTER INCLUDED):

1REPORT HEADER 

The new one where I had to make the LRECL 134 to avoid the abend looks
like 
this:

1 REPORT HEADER 

Does anyone know what can cause this (compiler option or PTF)?  I seem
to 
remember this happening a long time ago, but I have long forgotten what 
caused this, and how I fixed it.  

We are currently z/OS 1.8, and have been for about 7 weeks, and this
issue 
started around a week ago.  So I don't think it's an upgrade issue. 

Thanks 

Todd Burrell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Shooting of Commands

[Rick Fochtman]

---


Does anyone know how to shoot commands at particular time or on coming
of particular message in log.My intention is to start a started tasks
or jobs which do specific function However the Lpar where I want this
to be done is having none of the product for Automation or
   


Scheduling..
 



You do have 1 tool to issue commands at specific times: JES2 automatic
commands. 
Check the $TA command.
 


-
You can use MPF exits to trap particular messages going into the log. 
You can find some sample MPF exits in Greg Price's files on the CBT Tape 
site




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

Re: Weird COBOL issue

[Peter X. DeFabritus]

Todd, they probably compiled the program with the ADV compiler option.  The 
quote from the Enterprise COBOL Programmer's Guide is:

"With ADV in effect, the compiler adds 1 byte to the record length to account 
for the printer control character".

ADV is the default option.  This is a common point of confusion in COBOL.  
Recompiling with NOADV should solve the problem.

On Wed, 15 Aug 2007 11:09:34 -0500, Todd Burrell <[EMAIL PROTECTED]> wrote:

>All:
>We have a strange COBOL issue occurring, and I cannot remember what is
>causing this.  Starting a few days ago, when our programmers compile a cobol
>program and try to run it, their print files that should be 133 characters in
>length (RECFM=FBA) are failing with basically the old S001 abend, but in this
>case it is the message IGZ0201W about the record length mismatch, and then
>the job abends with a U4038 with additional message IGZ0035S indicating the
>file status 39 error.
>
>They can get the job to run by changing the LRECL to 134 instead of 133, 
and
>when I compare the current 134 length file with the old production run from
>last week that worked (LRECL 133) the only difference I see is an extra
>characer inserted before the first character of the record.  So the old record
>looks like this (PRINT CONTROL CHARACTER INCLUDED):
>
>1REPORT HEADER
>
>The new one where I had to make the LRECL 134 to avoid the abend looks like
>this:
>
>1 REPORT HEADER
>
>Does anyone know what can cause this (compiler option or PTF)?  I seem to
>remember this happening a long time ago, but I have long forgotten what
>caused this, and how I fixed it.
>
>We are currently z/OS 1.8, and have been for about 7 weeks, and this issue
>started around a week ago.  So I don't think it's an upgrade issue.
>
>Thanks
>
>Todd Burrell
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: linklisted load library failing

[Rick Fochtman]

-


And so, this is why I tell people to do their allocations for LNKLST or
CICS as only a primary, no secondary, CONTIG. And make the primary space
at least 25% larger than the used space once it is compressed
(especially so CICS).
 



I agree with the no-secondaries recommendation, but sometimes getting 
CONTIG space can be a chore. But also make sure that you allocate PLENTY 
of directory blocks! I can't think of too many things more frustrating 
than running out of directory blocks in a LINKLIST dataset!


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

CA to IBM TCP conversion

[Johnston, Robert E]

Hi all...

We are early in the process of moving from CA to IBM TCP/IP (still reading IP
config guide - good manual, BTW). We've used CA since it was Interlink in the
early 90's. I have the IBM stack running with a couple of ports and that's
about all that has been done with it. I like it so far but there is so much
to learn. I'm trying to get a feel about the best way to do things here.

We have some special telnet LU mapping that will need to be done but the main
thing I am concerned with is testing about a dozen or so socket applications.
We also use FTP quite a bit.

You can run both stacks at once, right?

Is it worth it to try and run both stacks at once? Once an app is tested we
would move it from the CA to IBM stack. (It looks kind of messy getting the
apps to use the correct stack.)

Would you forget about CA and just test everything with IBM?

We are also on the middle of z/OS 1.4 to 1.7 conversion. TCP conversion can
be included in the 1.7 upgrade or we can handle it separately. We're a small
shop, 3-man system team on a z800. I guess all I am looking for right now is
comments and suggestions. What say ye?

Thanks,
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ICKDSF Intilize question.

[Rick Fochtman]

OK, so you want to change the volser. How are you going to reset the catalog 
pointers?

I also worked at a shop with multiple LPARs with sets of volsers that were the 
same on each LPAR. Their reasoning was that it allowed for an easy refresh of 
the test LPARs.
 



Changing catalog pointers can be automated, for the most part, if you're 
good with the ISPF Editor.


Unfortunately, having duplicate vol-sers makes DASD sharing impossible, 
so making emergency repairs from another image can be very tedious.


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

Re: Weird COBOL issue

[Binyamin Dissen]

On Wed, 15 Aug 2007 11:09:34 -0500 Todd Burrell <[EMAIL PROTECTED]> wrote:

:>All:
:>We have a strange COBOL issue occurring, and I cannot remember what is 
:>causing this.  Starting a few days ago, when our programmers compile a cobol 
:>program and try to run it, their print files that should be 133 characters in 
:>length (RECFM=FBA) are failing with basically the old S001 abend, but in this 
:>case it is the message IGZ0201W about the record length mismatch, and then 
:>the job abends with a U4038 with additional message IGZ0035S indicating the 
:>file status 39 error. 

:>They can get the job to run by changing the LRECL to 134 instead of 133, and 
:>when I compare the current 134 length file with the old production run from 
:>last week that worked (LRECL 133) the only difference I see is an extra 
:>characer inserted before the first character of the record.  So the old 
record 
:>looks like this (PRINT CONTROL CHARACTER INCLUDED):

:>1REPORT HEADER 

:>The new one where I had to make the LRECL 134 to avoid the abend looks like 
:>this:

:>1 REPORT HEADER 

:>Does anyone know what can cause this (compiler option or PTF)?  I seem to 
:>remember this happening a long time ago, but I have long forgotten what 
:>caused this, and how I fixed it.  

:>We are currently z/OS 1.8, and have been for about 7 weeks, and this issue 
:>started around a week ago.  So I don't think it's an upgrade issue. 

Look at the changes.

If in the past you were just doing WRITEs without the ADVANCING/POSITIONING
clause and plugging in the carriage control and they have now added the
clause, COBOL may reserve an extra character.

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: Weird COBOL issue

[Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)]

That was it.  I have not done or looked at COBOL in a LONG time, so I
was not sure where to look.  Not I have to figure out who changed this
to not work, but that's my cross to bear. 

Thanks for the quick help. 

C. Todd Burrell
Senior z/OS Systems Programmer
ITSO
(404) 498-3299
(404) 723-2017 (cell)
 
Please visit the ITSO Customer Satisfaction Survey 
and tell us about your recent experiences with ITSO.
 
This survey is for internal CDC use only and the results 
will be used to improve business services.  
Anyone working for CDC in any capacity is invited to participate in our
survey.
 
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Peter X. DeFabritus
Sent: Wednesday, August 15, 2007 12:21 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Weird COBOL issue

Todd, they probably compiled the program with the ADV compiler option.
The quote from the Enterprise COBOL Programmer's Guide is:

"With ADV in effect, the compiler adds 1 byte to the record length to
account for the printer control character".

ADV is the default option.  This is a common point of confusion in
COBOL.  
Recompiling with NOADV should solve the problem.

On Wed, 15 Aug 2007 11:09:34 -0500, Todd Burrell <[EMAIL PROTECTED]> wrote:

>All:
>We have a strange COBOL issue occurring, and I cannot remember what is 
>causing this.  Starting a few days ago, when our programmers compile a 
>cobol program and try to run it, their print files that should be 133 
>characters in length (RECFM=FBA) are failing with basically the old 
>S001 abend, but in this case it is the message IGZ0201W about the 
>record length mismatch, and then the job abends with a U4038 with 
>additional message IGZ0035S indicating the file status 39 error.
>
>They can get the job to run by changing the LRECL to 134 instead of 
>133,
and
>when I compare the current 134 length file with the old production run 
>from last week that worked (LRECL 133) the only difference I see is an 
>extra characer inserted before the first character of the record.  So 
>the old record looks like this (PRINT CONTROL CHARACTER INCLUDED):
>
>1REPORT HEADER
>
>The new one where I had to make the LRECL 134 to avoid the abend looks 
>like
>this:
>
>1 REPORT HEADER
>
>Does anyone know what can cause this (compiler option or PTF)?  I seem 
>to remember this happening a long time ago, but I have long forgotten 
>what caused this, and how I fixed it.
>
>We are currently z/OS 1.8, and have been for about 7 weeks, and this 
>issue started around a week ago.  So I don't think it's an upgrade
issue.
>
>Thanks
>
>Todd Burrell
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GDG question

[Binyamin Dissen]

On Wed, 15 Aug 2007 11:10:54 -0400 "Hare, Tim" <[EMAIL PROTECTED]>
wrote:

:>I need to move some existing GDG datasets from tape to disk.  Normally, I 
would create a new version of each generation (V00 to V01, etc.), however these 
are created by a product which records the dataset name when they are created, 
and uses the actual name (whatever.G0001V00) when referencing the dataset. I 
therefore have to end up with the same names.

:>I can uncatalog the old dataset, and create the new dataset, in the same job; 
or I could create a new version, then later rename it. My main question is 
whether I need to do this in a specific order to avoid losing the oldest 
generation that exists?

I don't think that rollout applies when explicitly using the generation
numbers.

Just prevent new generations from being created while doing the move. And talk
to the vendor to provide a facility to edit the dsname. 

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: encrypted 3172 and 3174 controller replacement

[Hal Merritt]

For standard 'green screen', TN3270 with TLS is a good choice. Industry
standard and free. 

I would think that a hardware encryption solution would be in two
pieces: one local and one remote. Data would be flowing in the open to
the unit and from the unit on the other side. I would worry about TCO,
routine operations issues, and key management. 



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Jack Kelly
Sent: Wednesday, August 15, 2007 9:38 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: encrypted 3172 and 3174 controller replacement

Has anyone experience with SecureAgent IDG 9074 ? It's a surprising
afforadable encrypted 3172 and 3174 controller replacement and seems to
deliver on the marketing hype. I'm interested in any comparable
products/
TIA



Jack Kelly
LA Systems @ US Courts
x 202-502-2390

 
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively
for the individual or entity to which it is addressed. The message, together 
with any attachment, may contain confidential and/or privileged
information. Any unauthorized review, use, printing, saving, copying, 
disclosure 
or distribution is strictly prohibited. If you have received this message in 
error, please immediately
advise the sender by reply email and delete all copies.

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

Re: Attachmate

[Traylor, Terry]

If by PA1, you mean to interrupt your foreground session, then the Attn
key in TSO-ISPF.EQP in the QuickPads should do the trick.  You can find
QuickPads under Options then Settings.  You can also edit the QuickPads.


Terry Traylor 
charlesSCHWAB 
TIS Mainframe Storage Management 
Remedy Queue: tis-hs-mstg
(602) 977-5154 
WARNING:  All email sent to or from this address will be received by the
Charles Schwab corporate e-mail system and is subject to archival and
review by someone other than the recipient.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Grant Ward Able
Sent: Wednesday, August 15, 2007 7:55 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Attachmate

Does anyone know how to setup a quickpad in Attachmate for TSO-ISPF, to
send the PA1 key ?

--
Regards - Grant




DTCC DISCLAIMER: 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. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Listing HIPERS

[Sumi, Joseph J. (CMS/CTR) (CTR)]

Is there an easy way to list all HIPERS for a given time frame for my
licensed products z/OS and z/OS related productsor all z/OS products
? I have do IBMLINK

Thanks, Joseph Sumi

 


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

Re: Listing HIPERS

[Tergerson, John]

Joseph,

I think the easiest way to do this is to rely on ENHANCED HOLDDATA.
Make sure you have received current holddata, and then run an SMPE
report:

  SETBOUNDARY (GLOBAL)  .
  REPORT 
 ERRSYSMODS  
 ZONES(  
   MVST100   
   MVST111   
  )  
 NOPUNCH   . 

It will give you output like:

HOLD SYSMOD   APAR  ---RESOLVING SYSMOD   HOLDHOLD

FMID NAME NUMBERNAMESTATUS RECEIVED   CLASS   SYMPTOMS


---
 

HBB7730  HBB7730  AA06300  UA33609  HELD   YESHIPER
IPL,XSYS,SYSPLXDS
  AA16435  UA32817  GOOD   YESHIPER   FUL

  AA17009  UA32825  GOOD   YESHIPER   FUL

  AA17114  UA34633  GOOD   YESHIPER   IPL

  AA18380  UA32760  HELD   YESHIPER   FUL


 Hope that helps.
John


Confidentiality notice: The information included in this e-mail,
including any attachments, is for the sole use of the intended recipient
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure, distribution or similar action is
prohibited. If you are not the intended recipient, please contact the
sender and delete all copies of the original message immediately.


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Sumi, Joseph J. (CMS/CTR) (CTR)
Sent: Wednesday, August 15, 2007 1:20 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Listing HIPERS

Is there an easy way to list all HIPERS for a given time frame for my
licensed products z/OS and z/OS related productsor all z/OS products
? I have do IBMLINK

Thanks, Joseph Sumi

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

DASD Recovery

[Howard Rifkind]

Stupid Question.

I have an old test system and some of the DASD volumes
have had a init done on them.

Is there any recovery functin in ICKDSF that can
recover the data and votc entry.

Nothing has been done to these volumes since the init.

Or are we sool.

Thanks.


   

Looking for a deal? Find great prices on flights and hotels with Yahoo! 
FareChase.
http://farechase.yahoo.com/

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

Re: CA to IBM TCP conversion

[Ted MacNEIL]

>You can run both stacks at once, right?

Yes.

And, I would convert gradually, rather than all at once.

-
Too busy driving to stop for gas!

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

Re: DASD Recovery

[Ed Finnell]

 
In a message dated 8/15/2007 12:55:18 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

Or are  we sool.



>>
RESTORE from backup or FLASHCOPY from  production?



** Get a sneak peek of the all-new AOL at 
http://discover.aol.com/memed/aolcom30tour

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

Re: Listing HIPERS

[Sumi, Joseph J. (CMS/CTR) (CTR)]

I'm looking for something much easier.either using IBMLINK or
ShopzSeries to just get a list of HIPERS without having to pull
maintenance, etc. Thanks.

Rgrds, Joseph Sumi



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Tergerson, John
Sent: Wednesday, August 15, 2007 1:43 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Listing HIPERS

Joseph,

I think the easiest way to do this is to rely on ENHANCED HOLDDATA.
Make sure you have received current holddata, and then run an SMPE
report:

  SETBOUNDARY (GLOBAL)  .
  REPORT 
 ERRSYSMODS  
 ZONES(  
   MVST100   
   MVST111   
  )  
 NOPUNCH   . 

It will give you output like:

HOLD SYSMOD   APAR  ---RESOLVING SYSMOD   HOLDHOLD

FMID NAME NUMBERNAMESTATUS RECEIVED   CLASS   SYMPTOMS


---
 

HBB7730  HBB7730  AA06300  UA33609  HELD   YESHIPER
IPL,XSYS,SYSPLXDS
  AA16435  UA32817  GOOD   YESHIPER   FUL

  AA17009  UA32825  GOOD   YESHIPER   FUL

  AA17114  UA34633  GOOD   YESHIPER   IPL

  AA18380  UA32760  HELD   YESHIPER   FUL


 Hope that helps.
John

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

Re: CA to IBM TCP conversion

[Dana Mitchell]

Robert,

I went through this exercise in the late 90's, so memory is sketchy at best.
 Here's some points that I remember:

Conversion method depends on how comfortable you are with changing and
testing the TCP apps.   You may be able to switch apps from one stack to
another for testing successfully one at a time, but you still may run into
snags at full cutover time when Interlink is no longer there.  You might
consider setting up a test window on a weekend or perhaps a test system,
where z/OS is brought up with IBM's TCPIP in place and no trace of
Interlink/CA.  Then shake out each of the apps and decide when to cut over.
  Seems like IBM products and programs were generally better behaved than
ISV products.

At the time there were some functions that were supported on one stack but
not the other, that caused us problems (IUCV perhaps?)

In converting FTP control statements,  Interlink ignored cc73-80,  IBM's did
not.   Sequence numbers on control statements would be interpreted by IBM
FTP as port number, causing misleading errors such as connection timed out,
or invalid port.

Dana Mitchell

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

Re: linklisted load library failing

[Patrick O'Keefe]

On Wed, 15 Aug 2007 14:47:16 -0500, Paul Gilmartin 
<[EMAIL PROTECTED]> wrote:

>...
>100% in order to do an APPLY REDO (but that's a strange thing
>to do in a LINKLST library).  PDSE could make the situation
>better, even to the extent of needing only surplus space as
>large as the largest member; or worse, because space may not
>be reused until all address spaces CLOSE the data set.
>...

Worse (unless things have changed in that last couple years).
You don't run int the additional extent problem; you just run out of 
space that can't be reclaimed.  When I ran into this, every LPAR with 
the library in the LINKLIST had it allocated and open by LLA and 
XCFAS.  I assume it was the OPEN that kept the space from being 
reclaimed.

A royal pain!

Pat O'Keefe

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

Re: linklisted load library failing

[Paul Gilmartin]

On Wed, 15 Aug 2007 09:29:51 -0400, Thompson, Steve wrote:
>
>However, I have been reading the posts on this, and I think you may want
>to review all files in the LNKLST and ensure that that they are
>allocated as only PRIMARY space.
>
Should this recommendation also apply to libraries that are
kept open chronically, by multiple address spaces, such as
PROCLIB, and even ISPF source libraries?

>We tried refreshing LLA, VLF, etc., but until you dropped the whole
>linklist and picked up a new one (or IPLed), you were going to have
>problems.
>
I might expect that LLA refresh would not cause address spaces
other than the one causing the secondary allocation to refresh
their DEB lists.

>And so, this is why I tell people to do their allocations for LNKLST or
>CICS as only a primary, no secondary, CONTIG. And make the primary space
>
CONTIG should alleviate the 255 extents per concatenation constraint.
Is there any other benefit?

>at least 25% larger than the used space once it is compressed
>(especially so CICS).
>
100% in order to do an APPLY REDO (but that's a strange thing
to do in a LINKLST library).  PDSE could make the situation
better, even to the extent of needing only surplus space as
large as the largest member; or worse, because space may not
be reused until all address spaces CLOSE the data set.

-- gil

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

Re: SHARE Snubbery Report

[Patrick O'Keefe]

On Wed, 15 Aug 2007 10:31:11 -0500, John P Kalinich 
<[EMAIL PROTECTED]> wrote:

>Who has the most snubs so far?
>...

I've snubbed - and been snubbed by - everybody at SHARE.
But long distance snubery is too easy.  It probably doesn't count. 

Pat O'Keefe

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

Re: Tech Notes - Any body know about them or where they are hidden?

[Patrick O'Keefe]

On Tue, 14 Aug 2007 16:31:44 -0400, Thompson, Steve 
<[EMAIL PROTECTED]> wrote:

...
>>http://www-
03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs
>...
>No, that isn't it either.
>
>And nothing against you, but I'd bet that most of the SHARE 
attendees
>don't know what the Tech Notes are either, or where they are found.
>
>A small hint: they appear to be an attempt to replace the old TNLs.
>...

If they are a replacement for TNLs then there are at least 2 things
refered to as Tech Notes by IBM.  IBM's TCP/IP Support is using 
something they call Tech Notes as a replacement for Info APARs 
and entries in IBMLink's PD database.  (They may have done 
something about that latter point.)

Since I use green screen access to IBMLink as much as possible, I do
not find this switch to Tech Notes particularly welcome.

Pat O'Keefe

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

Re: DASD Recovery

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind
> Sent: Wednesday, August 15, 2007 12:55 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: DASD Recovery
> 
> 
> Stupid Question.
> 
> I have an old test system and some of the DASD volumes
> have had a init done on them.
> 
> Is there any recovery functin in ICKDSF that can
> recover the data and votc entry.
> 
> Nothing has been done to these volumes since the init.
> 
> Or are we sool.
> 
> Thanks.
> 

If you put the new VTOC at the same location as the old VTOC, then you
are SOL. The reason is that when you init a VTOC, it is reinitialized
(rewritten). If the new VTOC is at a different location from the old
VTOC, there it __might__ be possible to alter the pointer at the front
of the pack to point to the old VTOC location. I actually did this many
years ago when I reinit'ed the wrong volume, but the VTOC was in a
different location. Unfortunately, this was under DOS/VS and another
sysprog actually did the recovery using DOS DITTO. 

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

Re: SHARE Snubbery Report

[Michael Stack]

At 08:31 AM 8/15/2007, you wrote:

Who has the most snubs so far?

Regards,
John K


Just this morning I failed to snub Mark Zelden.


Michael Stack
Product Developer
NEON Enterprise Software, Inc.

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

Re: SHARE Snubbery Report

[John P Kalinich]

SHARE Attendee Mike Stack of the IBM Mainframe Discussion List 
 wrote on 08/15/2007 03:16:04 PM:

> At 08:31 AM 8/15/2007, you wrote:
> >Who has the most snubs so far?
> >
> >Regards,
> >John K
> 
> Just this morning I failed to snub Mark Zelden.
> 

Good Mike, recovery is near.

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

Re: Refreshing PDSEs (was: linklisted load library failing)

[Patrick O'Keefe]

On Wed, 15 Aug 2007 14:44:03 -0700, GAVIN Darren * OPS EAS 
<[EMAIL PROTECTED]> wrote:

>...
>With a PDSE when a member is deleted, or re-written to a larger 
block,
>the unused space it had occupied becomes available for immediate 
usage
>by the next write (STOR) activity.  It maintains a list of free blocks
>in the directory, nothing, including a library in a linklist or a CICS
>region should be preventing that from being updated.
>...

This has been discussed here before.  I haven't searched the 
archives and don't remember the details, but I think the PDSE 
space reclamation happens when the dataset is closed, not as 
soon as the member is deleted or replaced.  This close does not
take place for a dataset in the linklist of ultiple MVSs.

I could very well have the explanation wrong, and it may be woefully
out of data (as I said, this was over 4 years ago) but at the time
this was "working as designed" behavior.

Pat O'Keefe

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

Re: Refreshing PDSEs (was: linklisted load library failing)

[GAVIN Darren * OPS EAS]

PDS's have the reclaiming space issue, PDSE's should not.  

With a PDSE when a member is deleted, or re-written to a larger block,
the unused space it had occupied becomes available for immediate usage
by the next write (STOR) activity.  It maintains a list of free blocks
in the directory, nothing, including a library in a linklist or a CICS
region should be preventing that from being updated.

If a system is not doing this it is likely because there is a user exit
or SMS exit preventing it, or maybe forcing PDSE allocations to be a
PDS's.

The only time a PDSE might need a reorg itself, is when it has split the
library's directory over all the extents it has allocated.  This really
only happens in a heavily used source library.

As for IEBCOPY it needs a 3meg region size minimum when working with
PDSE's, as opposed to the 450K size when working with PDS's

Darren

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Gilmartin
Sent: Wednesday, August 15, 2007 1:40 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Refreshing PDSEs (was: linklisted load library failing)

On Wed, 15 Aug 2007 14:57:16 -0500, Patrick O'Keefe wrote:


Then, how much space does it take to refresh a PDSE by complete
replacement by IEBCOPY?  200% of the quiescent size?  Or does
IEBCOPY somehow cleverly optimize the space requirement.

But this is for integrity in case:

Address space A does a BLDL, FIND, or NOTE.

Address space B replaces or deletes the member that
address space A found.

Address space A then POINTs at the member.

But nowadays, {Z|H}FS directories are supported (read only) as
libraries by BPAM.  What then happens in the analogous case,
replacing PDSEs by UNIX directories?  Does the POINT or subsequent
READ fail as some sort of invalid reference?  Or does the NOTE
cause the open() of a descriptor of the underlying file, anchoring
it in place (although I might expect that unlike a library member
it might nonetheless be overwritten by a concurrent process)?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Refreshing PDSEs (was: linklisted load library failing)

[Patrick O'Keefe]

On Wed, 15 Aug 2007 15:40:26 -0500, Paul Gilmartin 
<[EMAIL PROTECTED]> wrote:

>...
>But this is for integrity in case:
>
>Address space A does a BLDL, FIND, or NOTE.
>
>Address space B replaces or deletes the member that
>address space A found.
>
>Address space A then POINTs at the member.
>...

And I'm sure our integrity was well protected, but it did extend 
what was going to be a brief outage.  My plan for implementing a 
new release of some brand-x product was
1. stop execution of the product on all LPARs
2. tell users to stay out of the product's ISPF interface.
3. copy the product's target linklib into the linklist library 
4. do an LLA, UPDATE= on all LPARs 
5. start things back up.

Instead, there was a step for allocating a new PDS, adding a 
STEPLIB to a few procs, and some blind trust that the old ISPF 
interface was compatable with the new release.

If I had been using a PDS rather than a PDSE (as had been the 
previous case, and was again after the next set of IPLs) the 
procedure would have contained

3a  delete all members from the library
3b  compress it
3c copy from the target library into the linklist library

Is there less of an integrity exposure there than with the PDSE?
I don't see it.  Maybe if I had done an LLA UPDATE right after 3a, 
but I could have done that with the PDSE, too.  (In fact I might 
have.  This was 4 or 5 years ago.)

Pat O'Keefe

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

Re: Refreshing PDSEs (was: linklisted load library failing)

[Ted MacNEIL]

>PDS's have the reclaiming space issue, PDSE's should not.  

With a PDSE when a member is deleted, or re-written to a larger block, the 
unused space it had occupied becomes available for immediate usage by the next 
write (STOR) activity.

Not entirely accurate.
If the member(s) are still in use the space will not be available.
This can run up to doubling the space.
-
Too busy driving to stop for gas!

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

Re: SHARE Snubbery Report

[Mark Zelden]

I've lost count.  Lots of folks from IBM-MAIN , IBM-ers and by many folks
from former clients of mine around the Chicago area.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: Refreshing PDSEs (was: linklisted load library failing)

[Paul Gilmartin]

On Wed, 15 Aug 2007 21:50:21 +, Ted MacNEIL wrote:

>>PDS's have the reclaiming space issue, PDSE's should not.
>
>With a PDSE when a member is deleted, or re-written to a larger block, the 
>unused space it had occupied becomes available for immediate usage by the next 
>write (STOR) activity.
>
>Not entirely accurate.
>If the member(s) are still in use the space will not be available.
>This can run up to doubling the space.
>
I believe I can concoct even a worse case:

Job A does a FIND for every member

Job B replaces every member before Job A CLOSEs

Job C does a FIND for every member

Job D replaces every member before Jobs A and C CLOSE

etc.

I see no upper bound.

-- gil

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

Re: Another "why did they do it this way?" question - SMF time stamps

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/11/2007
   at 11:37 AM, "R.S." <[EMAIL PROTECTED]> said:

>There are two answers:

FSVO two.

>1) Dino reason: "Because, in S/360-168..." Someone did it

That might be a dino reason if there were such a creature, but there
wasn't.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another "why did they do it this way?" question - SMF time stamps

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 08/10/2007
   at 03:10 PM, "McKown, John" <[EMAIL PROTECTED]> said:

>Does anybody know why the people who designed SMF decided to encode
>the date and time as FL4'hundredths of seconds after midnight' plus
>PL4'0cyyddd'? Why not just put in the STCK value?

Because there was no STCK at the time. OS/360 used the Interval timer
on S/360; by the time S/370 came along it was too late to change.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Age Poll Results: 49.47

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/11/2007
   at 08:08 PM, Shane <[EMAIL PROTECTED]> said:

>For as long as I've been in the business, it has not embraced new
>talent

When I started, it was routine to bring in operators and train them.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another "why did they do it this way?" question - SMF time stamps

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 08/10/2007
   at 06:52 PM, "Thompson, Steve" <[EMAIL PROTECTED]> said:

>Well, unless you were using a S/360-MOD 20

When did you see SMF records from a 360/20? OS/360 couldn't run on it.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another "why did they do it this way?" question - SMF time stamps

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Wednesday, August 15, 2007 1:47 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another "why did they do it this way?" question 
> - SMF time stamps
> 
> 
> In <[EMAIL PROTECTED]>,
> on 08/10/2007
>at 03:10 PM, "McKown, John" <[EMAIL PROTECTED]> said:
> 
> >Does anybody know why the people who designed SMF decided to encode
> >the date and time as FL4'hundredths of seconds after midnight' plus
> >PL4'0cyyddd'? Why not just put in the STCK value?
> 
> Because there was no STCK at the time. OS/360 used the Interval timer
> on S/360; by the time S/370 came along it was too late to change.
>  
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT

Thanks. That is the consensus, so is likely correct. I wasn't around in
the pre-S/370 era.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

Re: Another "why did they do it this way?" question - SMF time stamps

[Ted MacNEIL]

>That is the consensus, so is likely correct. I wasn't around in the pre-S/370 
>era.

I was: in University.

-
Too busy driving to stop for gas!

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

Re: DASD Recovery

[Howard Rifkind]

John and all...I'm sol on this one.

I'm going to try to rebuild the volume from data on
the production system.

Thanks again.

--- "McKown, John" <[EMAIL PROTECTED]>
wrote:

> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:[EMAIL PROTECTED] On Behalf Of Howard
> Rifkind
> > Sent: Wednesday, August 15, 2007 12:55 PM
> > To: IBM-MAIN@BAMA.UA.EDU
> > Subject: DASD Recovery
> > 
> > 
> > Stupid Question.
> > 
> > I have an old test system and some of the DASD
> volumes
> > have had a init done on them.
> > 
> > Is there any recovery functin in ICKDSF that can
> > recover the data and votc entry.
> > 
> > Nothing has been done to these volumes since the
> init.
> > 
> > Or are we sool.
> > 
> > Thanks.
> > 
> 
> If you put the new VTOC at the same location as the
> old VTOC, then you
> are SOL. The reason is that when you init a VTOC, it
> is reinitialized
> (rewritten). If the new VTOC is at a different
> location from the old
> VTOC, there it __might__ be possible to alter the
> pointer at the front
> of the pack to point to the old VTOC location. I
> actually did this many
> years ago when I reinit'ed the wrong volume, but the
> VTOC was in a
> different location. Unfortunately, this was under
> DOS/VS and another
> sysprog actually did the recovery using DOS DITTO. 
> 
> --
> John McKown
> Senior Systems Programmer
> HealthMarkets
> Keeping the Promise of Affordable Coverage
> Administrative Services Group
> Information Technology
> 
> The information contained in this e-mail message may
> be privileged
> and/or confidential.  It is for intended
> addressee(s) only.  If you are
> not the intended recipient, you are hereby notified
> that any disclosure,
> reproduction, distribution or other use of this
> communication is
> strictly prohibited and could, in certain
> circumstances, be a criminal
> offense.  If you have received this e-mail in error,
> please notify the
> sender by reply and delete this message without
> copying or disclosing
> it.
> 
>
--
> For IBM-MAIN subscribe / signoff / archive access
> instructions,
> send email to [EMAIL PROTECTED] with the message:
> GET IBM-MAIN INFO
> Search the archives at
> http://bama.ua.edu/archives/ibm-main.html
> 



   

Moody friends. Drama queens. Your life? Nope! - their life, your story. Play 
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/

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

Refreshing PDSEs (was: linklisted load library failing)

[Paul Gilmartin]

On Wed, 15 Aug 2007 14:57:16 -0500, Patrick O'Keefe wrote:
>
>>100% in order to do an APPLY REDO (but that's a strange thing
>>to do in a LINKLST library).  PDSE could make the situation
>>better, even to the extent of needing only surplus space as
>>large as the largest member; or worse, because space may not
>>be reused until all address spaces CLOSE the data set.
>
>Worse (unless things have changed in that last couple years).
>You don't run int the additional extent problem; you just run out of
>space that can't be reclaimed.  When I ran into this, every LPAR with
>the library in the LINKLIST had it allocated and open by LLA and
>XCFAS.  I assume it was the OPEN that kept the space from being
>reclaimed.
>
Then, how much space does it take to refresh a PDSE by complete
replacement by IEBCOPY?  200% of the quiescent size?  Or does
IEBCOPY somehow cleverly optimize the space requirement.

>A royal pain!
>
But this is for integrity in case:

Address space A does a BLDL, FIND, or NOTE.

Address space B replaces or deletes the member that
address space A found.

Address space A then POINTs at the member.

But nowadays, {Z|H}FS directories are supported (read only) as
libraries by BPAM.  What then happens in the analogous case,
replacing PDSEs by UNIX directories?  Does the POINT or subsequent
READ fail as some sort of invalid reference?  Or does the NOTE
cause the open() of a descriptor of the underlying file, anchoring
it in place (although I might expect that unlike a library member
it might nonetheless be overwritten by a concurrent process)?

-- gil

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

Re: z/OS 1.6 PTF for 32 CPs per LPAR

[Knutson, Sam]

Hi,

That is a trick question. There was no PTF.  

This was basically a statement of support no APAR fixes had to be
installed to enable the limit of 32.  The code in z/OS 1.6 supported 32
from day one.


Kathy Walsh wrote FLASH10401 on this

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10401 

Best Regards, 

Sam Knutson, GEICO 
System z Performance and Availability Management 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574 


Excellent firms don't believe in excellence Only in constant improvement
and constant change.
Tom Peters


-Original Message-
Does anyone know what z/OS 1.6 PTF changes the maximum number of CPs per
LPAR from 24 to 32?  I have done multiple searches and found that one
supposedly exists, but I can not find the exact PTF number.

Thanks in advance,
Steve

Stephen Bielskie
Assistant Vice President
IT -  z/OS Base Products - Princeton
KIUT 57

CREDIT  SUISSE  

Princeton, NJ  
Telephone : (609) 243-0711 
Email :[EMAIL PROTECTED]

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

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

Consolxx question with ICC

[Andy White]

Thought maybe someone could help us out there. We are starting to exploit 
using the ICC both for our local site and XRC site. The plan is to replace 
all of our old 3174 we are still using. Currently, the 3174 has one 
connection (addr 040) to a coax card in a device called a VCC (server/coax 
cards) in our command center. This allows the 23 workstations to be able 
to 'share' each addr 040 on each of the 23 work stations between the coax 
cards and the software on the server they can virtually share the same 
address on their screens without having to use 23 addresses just one. 

This way if workstation one wants to enter a command they take control of 
the console and do it through software/emulator. Then another person can 
enter a command if they want from another workstation without getting and 
changing work stations.

Under the ICC now we can share the console (new addr 1001) with all the 
work stations because the VCC cant do it at the moment like it can with 
Coax. 


Our problem is how could we share one console with each of the 23 work 
stations and maintain for example a 6 way sysplex. If we each one has 23 
console that would be 138 consoles and put me over (I think). I was 
thinking if we could disconnect the console close up a work station (sign 
off) and the operator for his/her shift goes home will the system under 
z/OS stay up? Any one  try this?


Here are the first questions

1) Under z/OS 1.8 how many consoles can you have per sysplex? I thought it 
was 99 and dont see where it might of changed. has it?
2) Under z/OS 1.8 can you disconnect a ICC console and will it stay up? 
(No console situation?) or because there is no Master this will work fine?


If anyone has ideas please reply, online or offline but PLEASE no sales 
people we aren't looking to purchase any more hardware for the consoles. 
Thanks

Andy
Internet: Mailto:[EMAIL PROTECTED]



The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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

Re: OSA-Express2 and SNA Pcomm - loss of connectivity

[Chris Mason]

Sheila

I was going to say - not that I can see nothing wrong with your 
definitions - I couldn't see why your definitions should not at least work - 
as indeed you said they do some of the time.


However I checked your definitions more precisely and - most importantly - 
checked for what you had *not* specified, namely the default values.


I was actually flabbergasted at what I spotted. And I'm not sure whether or 
not it is true. The standard of precision in VTAM documentation has gone 
down-hill in the last decade or so.[1]


What I spotted was that the default value for the DYNPU operand of the XCA 
major node GROUP statement is YES. I checked my presentation notes which 
cover the topic and I found that the default when the operand was introduced 
in the early '90s was NO - as it jolly well ought to be! How it has managed 
to get changed - if indeed it has changed - I obviously haven't a clue.


All that follows assumes that the default value for the DYNPU operand of the 
GROUP statement in the XCA major node really is YES.


The answer to your question over whether or not anyone has experienced your 
problem is, possibly, also "yes"! I have had to resolve this problem 
before - about 10 years ago - but then the problem was that DYNPU had 
actually been coded as DYNPU=YES. The poor IBM systems engineer had made the 
gross error of copying parameters from a redbook example without 
understanding what each one did - as had, of course, the redbook authors - 
and their advisor - and any possibly savvy reviewers also hadn't spotted the 
danger.


What may have happened from when your definitions worked to when they no 
longer worked is that you activate the OSA port using the XCA major node 
***before*** you activate the switched major nodes. This is very probably a 
matter of the order of specification of the names of major node members in 
your ATCCONxx member.


The effect of this is that, as a PCOMM node tries to connect to the newly 
initiated VTAM, the request to connect is satisfied dynamically and, in 
effect, a default switched PU definition is assigned to the PCOMM node. This 
default definition will have only the SSCP-independent LU with the same name 
as you defined for the CP within PCOMM assuming you have CPCDRSC=YES, not 
the default, in your VTAM start options. The name given to the dynamically 
created PU statement will begin with "CN" since you have not specified the 
DYNPUPFX operand to have a value other than the default.


Once the switched major nodes become active, the individual PU minor node 
definitions will sit there quietly in CONCT status, there being no reason 
for them ever to become connected. Or maybe they'll be in RELSD status - or 
something like that - since for them to become active would imply an 
identification conflict. I'm afraid I'm not in a position to test out my 
conclusions these days.


So, if the default value for DYNPU is indeed YES these days and you do *not* 
want to use the default dynamic PU statement definition for your PCOMM 
connections - which you clearly don't, you should specify DYNPU=NO on the 
GROUP statement of the XCA major node.


You could simply position the switched major node names earlier in the 
sequence of names in the ATCCONxx member so that they appear before the name 
of the XCA major nodes - but that's living dangerously! Who knows what the 
next person to respecify the names in ATCCONxx might decide to do?


Reviewing you post again, the problem is not that a connection fails to take 
place. A connection does take place, it's just not the connection you want.


Strictly, I would expect that "bouncing the XCA" would fix the problem. 
Maybe either OSA port will accept the perpetual connection attempts from the 
PCOMM nodes and you did not "bounce" both XCA major nodes at the same time. 
The point is that, after the "bounce", the switched PU definitions will be 
waiting, as it were.


---

If all this does not turn out to be the solution, please follow up on my 
other request and indicate more about the configuration of nodes - and 
protocols - from the OSA port to the PC running PCOMM.


Also please be sure to note what connections may be taking place and whether 
or not the PCOMM nodes show a connection - even if the PU entity and the LU 
entities are not active (excluding the LU with the same name as the CP which 
may be able to initiate sessions anyhow).


---

Regarding "not that I can see nothing wrong with your definitions", I'll try 
to post again with some observations on the definitions you supplied with a 
view to reducing them to essentials and possibly introducing some 
improvements in, for example, performance and dynamism!


---

Perhaps your comments about Cisco related to Eric's comments about the 
relative "solidity" of Cisco routers and 3745s. This is actually an unfair 
comparison. What is different between Cisco routers and the 3745 is the 
suitability of the underlying technology. For reliable business-oriente

Re: z/OS 1.6 PTF for 32 CPs per LPAR

[Timothy Sipples]

FWIW, z/OS 1.9 increased this number yet again to 54.  Thus on a System z9
EC Model 754 you can configure a single z/OS 1.9 LPAR spanning the whole
machine if you desire.  See IBM Announcement Letter 207-175.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]

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

Re: z/OS 1.6 PTF for 32 CPs per LPAR

[Mark Zelden]

On Thu, 16 Aug 2007 13:47:10 +0900, Timothy Sipples
<[EMAIL PROTECTED]> wrote:

>FWIW, z/OS 1.9 increased this number yet again to 54.  Thus on a System z9
>EC Model 754 you can configure a single z/OS 1.9 LPAR spanning the whole
>machine if you desire.  See IBM Announcement Letter 207-175.
>

And just like the code in z/OS 1.6 that supported 32 engines from day one,
I wouldn't be surprised if the code in 1.9 supported 64 - even though there
is no processor available today that has 64 engines.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: Consolxx question with ICC

[Bruce Hewson]

Andy,

You don't "need" any physical consoles..z/OS seems to run real fine.

We have a few sysplex's here setup without any physical consolesno 
3x74's, no 2074's, no Visara, no ICC.

For console access, we use:-

1:  HMC Operator Messages interface
2:  SMCS consoles work real fine, especially in multi-lpar sysplex.

The reason I said "seems" above is that I have been told by an IBM support 
person that some functions require a "real" console. Specifically in relation 
to 
the internally generated "D U" commands issued after a range of devices are 
varied on or off-line. I had reported an error at z/OS 1.6 level, but now at 
z/OS 1.7 there is no problem. :-(

I recommend you investigate SMCS consoles.

Regards
Bruce Hewson

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