Re: Sun/STK T10K tape drives and HSM

2009-04-13 Thread Larre Shiller
Hi Dave -

Well... ultimately, yes.  There were quite a few (internal) issues that needed 
to get worked through, not the least of which was a microcode problem with 
the T10K dives attached to the Sun Key Management Server that caused an 
erroneous timeout and IOS000I message when the Server is being backed up.  
But once we got everything corrected, it all seems to be working as designed 
and we are using the default 97 PERCENTFULL value.  The ML2 recall times 
have been slightly increased as compared to the 9840C, but the backups run 
lickedy-split.

Thanks for asking.

Larre Shiller
US Social Security Administration
The contents of this message are mine personally and do not necessarily 
reflect any official position of the US Government or the US Social Security 
Administration.

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


Re: New TOD

2009-04-13 Thread Don Poitras
In article p06240801c60847976...@[192.168.1.11] you wrote:
 At 18:32 + on 04/12/2009, john gilmore wrote about Re: New TOD:

 In particular, as I noted on another occasion, calendrical arihmetic 
 is rendered trivial when dates are stored as the signed number of 
 elapsed days from some epoch origin, of which the two reasonable 
 ones are:
 
 or 2) midnight 31 December , which is the epoch origin of the 
 Gregorian calendar,

 The Gregorian Calendar did not start sometime from 1582 (for the 
 Roman Church) to 1752 (the UK and the US [American Colonies at that 
 point]) through 1926 (Turkey) so you have to state what country you 
 are talking about. The skipping of anywhere from 10 to 13 days in the 
 switch from the Julian Calendar also screws up dates (for example 
 Washington's Birthday is NOT celebrated on his actual birthday since 
 he was born on a Julian (OS/Old Style) date/year.

The switchover to Gregorian is only needed when trying to figure
out some historical event. Both Julian and Gregorian Calendars come
in proleptic versions though which just roll both directions in
time forever. 

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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


Re: Sun/STK T10K tape drives and HSM

2009-04-13 Thread John Kelly
Radoslaw thanks for the update.

I never said that I was using TS... drives. If fact I was using STK 9840 
which indeed to emulate 3490s and it was an example.

Jack Kelly
202-502-2390 (Office)

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


RECORD OUT OF SEQUENCE in UCAT

2009-04-13 Thread Juan Vicente Rodríguez Puertas
Hi,

We got the following erros when we try to export a user catalog.

   EXPORT CAT.USUARIO.MUTUA OUTFILE(CINTASA) 
TEMPORARY  
IDC3302I  ACTION ERROR ON CAT.USUARIO.MUTUA 
IDC3314I **RECORD OUT OF SEQUENCE - KEY 
FOLLOWS:
00  C4C5E2F0 F14BC1E3 F1F04BE3 F5F44BE2   E8E2D6E4 E3F14040 
40404040 4040404
20  40404040 40404040 40404040 00   

IDC3302I  ACTION ERROR ON CAT.USUARIO.MUTUA 
IDC3308I ** DUPLICATE RECORD - KEY FOLLOWS: 
00  C4C5E2F0 F14BC1E3 F1F04BE3 F5F44BE2   E8E2D6E4 E3F14040 
40404040 4040404
20  40404040 40404040 40404040 00   

IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 
12  

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 
12  

We were searching IBM-Main archives and we found this post

Item#   Date  Time   Lines Subject 
034704 2006-06-26 14:38   95   Record out of sequence error on UCAT 

Unfortunaly nobody answered to it.

Is there a way to delete the records causing the error?

Could someone help us?

TIA

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


Re: z/OS 1.10 upgrade issue....Compuware

2009-04-13 Thread Jousma, David
All,

Just a heads up.  I just wanted to pass along another upgrade problem we
encountered that was a showstopper until fixed.  The problem was not
noticed for a couple days after our first development system upgrade. 

We run Compuware Expediter/TSO V7.6 and utilized the DB2 Stored
Procedure support(started tasks that runs at IPL time, installs hooks,
and goes away) in our development environments, and application
programmers noticed after upgrade that nested DB2 Stored procedures
would timeout (SQL code -471) 100% of the time on the upgraded system.  

After opening a ticket with IBM DB2 support, IBM determined that this is
a Compuware problem.  Xpediter/TSO PTF XTF0118 was required along with
an IPL to fix the problem.

I only post this because Compuware has not yet posted this fix on
Frontline, nor was included in the z/OS 1.10 required maintenance list
from them as late as last Friday.

_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497


This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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


Re: INFOPAC

2009-04-13 Thread Cynthia Davis
Ron, 
We had similar issues and after putting in question to ASG we were told to apply
IBM APAR OA26106.  





From: Ron Wells rwe...@agfinance.com
To: IBM-MAIN@bama.ua.edu
Sent: Friday, April 10, 2009 10:52:00 AM
Subject: INFOPAC

Having problem since we upgraded to RSU0812  think it maybe product but 
thought I'd hit list first..

INFOPAC Mobius sweeps we are now getting S80A-10  ... keep bumping up 
region= and sometime it works sometimes just restarting it works..

Anyone out here see problems with region sizes??

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are 
not  the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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


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


Re: Secondary space allocation

2009-04-13 Thread larry macioce
Ted, My reading is what I meant as scary..I was making a joke of it
mace

On Wed, Apr 8, 2009 at 12:25 PM, Ted MacNEIL eamacn...@yahoo.ca wrote:

 I always thought when you gave a secondary
 space allocation that it went to 16 extents(if needed), but I am reading
 that it now goes to 123.
 Is this true??

 PS/PO total extents allowed, per volume, 16.
 In theory, you could have 16 extents, even without a secondary specified.

 VSAM/Extended Function total extents allowed, per volume, 123.

 Why is it scary?
 In general, I'd rather have multiple extents/volumes, than abend.

 -
 Too busy driving to stop for gas!

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


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


Re: RECORD OUT OF SEQUENCE in UCAT

2009-04-13 Thread John McKown
On Mon, 13 Apr 2009 07:10:05 -0500, Juan Vicente Rodríguez Puertas
jvr...@mapfre.com wrote:

Hi,

We got the following erros when we try to export a user catalog.

   EXPORT CAT.USUARIO.MUTUA OUTFILE(CINTASA)
TEMPORARY
IDC3302I  ACTION ERROR ON CAT.USUARIO.MUTUA
IDC3314I **RECORD OUT OF SEQUENCE - KEY
FOLLOWS:
00  C4C5E2F0 F14BC1E3 F1F04BE3 F5F44BE2   E8E2D6E4 E3F14040
40404040 4040404
20  40404040 40404040 40404040 00

IDC3302I  ACTION ERROR ON CAT.USUARIO.MUTUA
IDC3308I ** DUPLICATE RECORD - KEY FOLLOWS:
00  C4C5E2F0 F14BC1E3 F1F04BE3 F5F44BE2   E8E2D6E4 E3F14040
40404040 4040404
20  40404040 40404040 40404040 00

IDC3003I FUNCTION TERMINATED. CONDITION CODE IS
12

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS
12


Well, my first thought would be to try to copy the catalog records using
other methods. Depending on the criticality and activity on the catalog, I
might try:

1) LOCK the catalog using IDCAMS
   ALTER catalog LOCK
2) backup the catalog using DFDSS or FDR.

3) Create a _NEW_ user catalog.

4) For each alias in the OLD catalog, do a REPRO MERGECAT to try to copy the
entries for that alias to the new catalog. If the MERGECAT works, then point
the alias to the NEW catalog.

5) If all the aliases are successfully moved to the NEW catalog, then delete
the OLD catalog using the FORCE PURGE and RECOVERY parameters.

6) If desired, continue using the NEW catalog, or reverse the process that
you did above to put the catalog entries into a NEW catalog with the OLD name.

If the catalog is too active or too critical, then I'm up a creek as to what
I'd actually do. I would definitely back up the catalog. I would then try to
determine the duplicate DSN in the catalog and see if I could somehow DELETE
it. 

--
John

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


Re: New TOD

2009-04-13 Thread john gilmore
Robert A. Rosenberg wrote:
 
. . . The Gregorian Calendar did not start sometime from 1582 (for the Roman 
Church) to 1752 (the UK and the US [American Colonies at that point]) through 
1926 (Turkey) so you have to state what country you are talking about. The 
skipping of anywhere from 10 to 13 days in the switch from the Julian Calendar 
also screws up dates (for example Washington's Birthday is NOT celebrated on 
his actual birthday since he was born on a Julian (OS/Old Style) date/year.
 
Paul Claudel wrote:
 
Rien n'est plus dangereuse qu'une idée quand on n'en a qu'une.  
 
Mr. Rosenberg has assimilated the notion that the Gregorian calendar was 
officially adopted at different times in different places and nothing else 
about it that is not the common stock of the subliterate.
 
One converts from another calendar's source day number to a target Gregorian 
day number by adding the Gregorian day number of the source calendar's epoch 
origin to the source day number.  
 
For example oonverts from a[n astonomical] Julian Day Number J to a Gregorian 
day number G using
 
G = J - 1721424.5
 
because -1721424.5 is the GD of noon, November 24, -4713, which is the GD of 
the epoch origin of the astronomical Julian calendar.
 
Or again if one wishes to convert a an Islamic AH (Anno Hegirae) day number 
into a Gregorian one G, one uses
 
G = H + 227015
 
because 227015 is the GD of the epoch origin of the Islamic calendar, 19 July 
622 in the Gregorian calendar.
 
Mr. Rosenberg confused the astronomical Julian calendar, which is the [only] 
one I wrote about, labelling it clearly as such, with the [Roman] Civil Julian 
calendar, which is the one that was supplanted by the Gregorian calendar for 
official use at different times in different places.  (The Civil Julian 
calendar was promulgated by Julius Caesar on 1 January 709 AUC, -79 of the 
Civil Julian calendar; the astronomical Julian calendar was promulgated by 
Joseph Scaliger in 1635; and their epoch origins are of course different.)
 
To repeat now, converting a day number from its value for a source calendar to 
its value for a different target calendar does not abolish the source calendar. 
  The official adoption of the Gregorian calendar in Russia in 1918 at the 
behest of Lenin did not abolish the Roman version of the Julian calendar.  (It 
continues to this day to be used by the Orthodox churches to fix the date of 
Easter.)
 
Moreover, The dates of events that occurred before the epoch origin of a 
particular calendar can nevertheless be stated in that calendar, i.e., using 
that calendar's conventions.  Their day numbers are of course negative; and 
when, infrequently, they need to be characterized as such, there is a word 
available for doing so: they are called proleptic dates.  (The adjective 
proleptic has also sometimes been applied to all dates that precede a 
calendar's promulgation date.)
 
All this is perhaps a little hard on Mr. Rosenberg, whose comments about 
programming [proper] topics have always in my experience been informed and 
useful ones; but the notion that calendrical computations are very much more 
complex than they appear to be is important.  Few of us calculate our own sines 
and cosines.  We use subroutines provided by specialists to do so, or we make 
fools of ourselves, and we should adopt this practice for calendrical 
computations too. 

John Gilmore Ashland, MA 01721-1817 USA



_
Rediscover Hotmail®: Get e-mail storage that grows with you. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Storage1_042009
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


IEFU29 and Automation

2009-04-13 Thread Lizette Koehler
I am having a discussion with a coworker about whether or not we need to run 
IEFU29.  We have OPS/MVS in house.  I say that we do not need IEFU29 because 
OPS/MVS can trap on the IEE388I SMF NOW RECORDING ON VOLSER DCSMF3, 
DSN=SYS1.SPG7.MAN3 TIME=10.30.00 message, display the man files at that point 
and the issue the Dump command for the correct MAN file.

My coworker says we have to run the IEFU29 exit to do this.

I know we could put the IEFU29 in place, but I think the less exits to maintain 
the better.

Any thoughts?

Lizette

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


Re: New TOD

2009-04-13 Thread Howard Brazee
On 13 Apr 2009 06:41:10 -0700, john_w_gilm...@msn.com (john gilmore)
wrote:

. . . The Gregorian Calendar did not start sometime from 1582 (for the Roman 
Church) to 1752 (the UK and the US [American Colonies at that point]) through 
1926 (Turkey) so you have to state what country you are talking about. The 
skipping of anywhere from 10 to 13 days in the switch from the Julian Calendar 
also screws up dates (for example Washington's Birthday is NOT celebrated on 
his actual birthday since he was born on a Julian (OS/Old Style) date/year.

Don Miguel de Cervantes died  - on April 23, 1616.
William Shakespeare died 10 days later - on April 23, 1616.

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


Re: IEFU29 and Automation

2009-04-13 Thread John McKown
On Mon, 13 Apr 2009 11:14:15 -0400, Lizette Koehler
stars...@mindspring.com wrote:

I am having a discussion with a coworker about whether or not we need to
run IEFU29.  We have OPS/MVS in house.  I say that we do not need IEFU29
because OPS/MVS can trap on the IEE388I SMF NOW RECORDING ON VOLSER DCSMF3,
DSN=SYS1.SPG7.MAN3 TIME=10.30.00 message, display the man files at that
point and the issue the Dump command for the correct MAN file.

My coworker says we have to run the IEFU29 exit to do this.

I know we could put the IEFU29 in place, but I think the less exits to
maintain the better.

Any thoughts?

Lizette

We did exactly as you propose to do. We removed our IEFU29 exit, replacing
it with a CA-OPS/MVS II rule. However, we trap IEE391A as that shows the DSN
which just filled up and needs dumping. The IEE388I message shows the NEW
DSN which is now in use. You don't want to try to dump that one.

--
John

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


Re: IEFU29 and Automation

2009-04-13 Thread Mark Zelden
On Mon, 13 Apr 2009 11:14:15 -0400, Lizette Koehler
stars...@mindspring.com wrote:

I am having a discussion with a coworker about whether or not we need to
run IEFU29.  We have OPS/MVS in house.  I say that we do not need IEFU29
because OPS/MVS can trap on the IEE388I SMF NOW RECORDING ON VOLSER DCSMF3,
DSN=SYS1.SPG7.MAN3 TIME=10.30.00 message, display the man files at that
point and the issue the Dump command for the correct MAN file.

My coworker says we have to run the IEFU29 exit to do this.

I know we could put the IEFU29 in place, but I think the less exits to
maintain the better.



I've done it both ways.  Here, we use IEFU29 but used to use automation on
a few of monoplex LPARs.  I standardized on IEFU29 sometime after
I started working here.  

One advantage that the automation had was that when shutting down LPARs
you can leave a MANx file that still needs to be dumped (too late in the
shutdown process for it to be started), then the next time you IPL it will
start recording on the first one which leaves a MANx file that needs to
be dumped.  The old automation used to include a  D SMF at IPL time
and dump those MANx files that required it.   

There were 2 solutions I had for that.  

1) Ignore it.  As long as there were enough MANx data sets to handle
the load, the SMFDUMP program that runs after midnight dumps them
all anyway (in addition to doing a switch).  MXG doesn't care if the SMF
data is out of order anyway.

2)  Use a proc like the following at IPL time and S SMFDUMP,ALL=TRUE
(I only use this in my sandbox LPARs that don't have automation nor
SMF daily processing):


//SMFDUMP PROC MAN='X',ALL=FALSE
//* 
//* THIS PROC IS NORMALLY STARTED VIA IEFU29 SMF EXIT WHEN AN   
//* SMF DATA SET SWITCH OCCURS (ONLY THE FIRST STEP RUNS):  
//*S SMFDUMP,MAN=SMF.DATA.SET.NAME  
//* 
//* AT IPL TIME IS IS STARTED AS FOLLOWS TO RUN THE SMFDUMP 
//* PROGRAM TO ENSURE ALL FULL SYS1.MANX DATA SETS ARE DUMPED:  
//*S SMFDUMP,ALL=TRUE   
//* 
//* IT IS ALSO STARTED THIS WAY AT MIDNIGHT TO USE THE SMFDUMP  
//* PROGRAM WHICH FORCES AN SMF SWITCH IN ORDER TO CAPTURE ALL  
//* THE SMF DATA UP TO THAT POINT FOR DAILY PROCESSING. 
//* 
//TESTEXEC EXEC PGM=IEFBR14 
//* 
//  
//TESTONE  IF (TESTEXEC.RUN NE ALL) THEN   
//  
//DUMPONE  EXEC PGM=IFASMFDP,TIME=1440  
//SYSPRINT DD SYSOUT=*  
//DUMPIN   DD DSN=MAN,DISP=SHR 
//DUMPOUT  DD DSN=hlq.SYSNAME..SMF(+1),DISP=(,CATLG),  
// DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, 
// SPACE=(CYL,(100,100),RLSE)   
//SYSINDD DUMMY 
// ENDIF
//  
//TESTALL  IF (TESTEXEC.RUN EQ ALL) THEN   
//  
//DUMPALL  EXEC PGM=SMFDUMP,TIME=1440   
//SYSPRINT DD SYSOUT=*  
//DUMPOUT  DD DSN=hlq.SYSNAME..SMF(+1),DISP=(,CATLG),  
// DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, 
// SPACE=(CYL,(100,100),RLSE)   
//SYSINDD DUMMY 
// ENDIF   
  

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: IEFU29 and Automation

2009-04-13 Thread Ed Finnell
 
In a message dated 4/13/2009 10:54:35 A.M. Central Daylight Time,  
stars...@mindspring.com writes:

I know we could put the IEFU29 in place, but I think the less exits to  
maintain the better.

Any thoughts?



Guess I'm with the EXITs crowd. May be  instances where OPS/MVS needs to be 
down or fixed while rest of system chugs  along.




**The Average US Credit Score is 692. See Yours in Just 2 Easy 
Steps! 
(http://pr.atwola.com/promoclk/100126575x1221621489x1201450100/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26h
mpgID%3D62%26bcd%3DAprilAvgfooterNO62)

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


Re: RECORD OUT OF SEQUENCE in UCAT

2009-04-13 Thread Ed Finnell
 
In a message dated 4/13/2009 8:52:48 A.M. Central Daylight Time,  
joa...@swbell.net writes:

If the catalog is too active or too critical, then I'm up a creek as to  
what
I'd actually do. I would definitely back up the catalog. I would then  try 
to
determine the duplicate DSN in the catalog and see if I could  somehow 
DELETE



Guess I'd start with DIAGNOSE for UCAT and  VOL. Most caused often by 
hardware failure or dup updates from multiple  systems. Maybe if we can clean 
up 
DES01 hlq the rest of UCAT will be  OKAY.
 
To get handle on hlq's do --- listc  ent('ucat_name') all




**The Average US Credit Score is 692. See Yours in Just 2 Easy 
Steps! 
(http://pr.atwola.com/promoclk/100126575x1221621489x1201450100/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26h
mpgID%3D62%26bcd%3DAprilAvgfooterNO62)

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


QSAM - Blocking logic defect for VB file?

2009-04-13 Thread Johnny Luo
Hi,

One of our customers had a problem in their production batch jobs. One COBOL
program writes variable length records to a VB PS data set and after
smoothly running for ten years the program begun to generate VB files with
invalid RDWs as reported by DFSORT which is used to copy the files.  We are
at z/OS 1.9.

I first wrote a program to read the physical blocks and parsed each block
using BDW/RDW mechanism. It shows that there are 97 blocks which contain
invalid RDW(RDW4 or RDWLRECL)。No problem found in BDW. They just match the
physical length of corresponding block.

To find the real problem I decided to parse the blocks in a different way.
The COBOL program builds the records as following:

1. After RDW each record contains a 8-byte identifier string 'BGLGLGP ';
2. 120 bytes from identifier string is a two-bytes length field which
contains the length of the variable data of the record;
3. Then comes the variable length part.

So I use the string ''BGLGLGP ' as delimiter to separate each record and
then find its 'real' RDW value in the 4-byte area just before the identifier
string.  I also use the two-byte length field set by user program to
calculate the supposed RDW value.

This time the result is more enlightening. All 97 'bad' blocks are in the
same pattern: (the following is simplified just to illustrate)

 -
| BDW  | RDW1 |   REC1 | RDW2 | REC2  |
 -
1. BDW matches the actual length of the block;
2. RDW1 and RDW2 all match the 'should-be' RDW value calculated from length
field set by application program;

The problem lies in the actual record length.  For REC1, its actual length
is shorter or longer than RDW1 indicates!

When DFSORT or other application like ISPF tries to parse the block via RDW,
it found no problem with record1 cause the value of RDW1 is valid. But it
will get the wrong start address of record2 via RDW1 cause the actual length
of REC1 is not as RDW1 indicates.  That's means it will select the wrong
area as RDW2 and its value is unpredictable.  Thus the so-called 'invalid
rdw'.

How does this happen? I can only think of one situation, that is, when QSAM
is building the block.  After moving record1 into the block, record2 should
be placed right after record1. If for some reason QSAM failed to do so,
record2 will overlay part of record1 or be placed far behind record1.  That
will generate a 'bad' block exactly as what we saw in this case.

To make things more complicated, the customer found one of their channel
paths could not be vary online when they tried to re-IPL the system. So they
temporarily discard the use of that path and then suddenly the problem
disappears.

Now the customer believe the problem is caused by that channel path and they
have reported the problem to IBM.

For me it's hard to accept it cause I cannot see the relationship. Write
operation does involve the interacion with channel subsystem but from my
limited knowledge after QSAM finished the building of the block all the left
operations are at block level and will not touch the inner structure of the
block.  It's nearly impossible for them to generate a 'bad' block exactly as
we saw in this specific case even if truncating or overlay occurs.  So I
still believe the cause of the problem is that QSAM somehow failed to build
the block right.

Any one can give me some hints?


-- 
Best Regards,
Johnny Luo

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


Re: IEFU29 and Automation

2009-04-13 Thread Ted MacNEIL
Guess I'm with the EXITs crowd. May be  instances where OPS/MVS needs to be 
down or fixed while rest of system chugs  along.

I agree.
And, it's not as if you have to write IEFU29 from scratch.

-
Too busy driving to stop for gas!

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


Re: IEFU29 and Automation

2009-04-13 Thread Lizette Koehler
Thanks everyone.  I will go without the exit.  Reason is due to no assembler 
coders here to support it.  I am the only one that can code assembler and if it 
breaks and I am not here, well you know.  ;-Q

Lizette




Guess I'm with the EXITs crowd. May be  instances where OPS/MVS needs to be 
down or fixed while rest of system chugs  along.

I agree.
And, it's not as if you have to write IEFU29 from scratch.


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


MQ Bridge - Transaction BKBP not start

2009-04-13 Thread Alvaro Quintupray Burgos
Hi.

We have ZOS  1.8  , MQ  6.0   and CICSTS 3.1   ... and cant not start the 
CKBP transaction ...   when I put the first message into the queue i getting 
the following in CICS  MSGUSR sysout...


IBM WebSphere MQ for z/OS V6 - CICS bridge 
Monitor initialization complete
Auth=LOCAL, WaitInterval=2, Q=SYSTEM.CICS.BRIDGE.QUEUE 

In addition  I have defined the models ...  

PREFIX(DF++) LOCATION(AUXILIARY) RECOVERY(NO) SECURITY
(NO)  
 
PREFIX(CKB+) LOCATION(AUXILIARY) RECOVERY(NO) SECURITY
(NO)  


What's happened ..?

Thanks.

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


Re: IEFU29 and Automation

2009-04-13 Thread John McKown
On Mon, 13 Apr 2009 16:28:07 +, Ted MacNEIL eamacn...@yahoo.ca wrote:

Guess I'm with the EXITs crowd. May be  instances where OPS/MVS needs to be
down or fixed while rest of system chugs  along.

I agree.
And, it's not as if you have to write IEFU29 from scratch.

-

True. The reason that my shop migrated from IEFU29 to CA-OPS/MVS II is
mainly that REXX is easier to write than HLASM. Our general rule is minimal
customization so that future fools (my classification) can still maintain
the system. 

This even applies to Windows applications - our ticketing system was just
upgraded and can no longer auto logon because the new admins don't know how
to do it. That was a customization by a former admin who knew how to
program. The new admins don't know how to program to script, so if it is
not supported out of the box, it can't be implemented.

Also, it is easier to change an OPS rule than the IEFU29 exit in the
one-in-a-million chance that some change is needed.

--
John

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


Re: IEFU29 and Automation

2009-04-13 Thread Mark Zelden
On Mon, 13 Apr 2009 11:07:14 -0500, Mark Zelden mark.zel...@zurichna.com
wrote:



I've done it both ways.  Here, we use IEFU29 but used to use automation on
a few of monoplex LPARs.  I standardized on IEFU29 sometime after
I started working here.

snip


I guess I should have given a reason for my choice.   My team doesn't
install the automation software nor can we update / control it in any
way.  I wanted control over this process since it is an operating system
function that we are responsible for.  If something changes due to an
OS migration, PTF, etc., we can change it without coordinating it with
the automation folks.   A good example will be if / when we migrate
to SMF logstreams.

If this shop ran like some smaller shops I've been at where the MVS 
sysprogs install the automation or can at least update / change the automation,
I wouldn't care as much.  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


z/OS 1.10 Enhancement: Predictive Failure Analysis

2009-04-13 Thread Brian Peterson
In case you missed this, IBM has just released a new function for z/OS 1.10
called Predictive Failure Analysis (PFA) which is now available.

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

This new feature is built upon the z/OS Health Checker infrastructure, and
is apparently the basis for future new capabilities.  Quoting from the
above, PFA will be extended over time..

The feature is available in the PTFs for APAR OA27165.

Brian

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


Re: z/OS 1.10 Enhancement: Predictive Failure Analysis

2009-04-13 Thread Richard Pinion
In the movie 2001, remember how well HAL's PFA worked!

--- brian.peterson.ibm.m...@comcast.net wrote:

From: Brian Peterson brian.peterson.ibm.m...@comcast.net
To: IBM-MAIN@bama.ua.edu
Subject: z/OS 1.10 Enhancement: Predictive Failure Analysis
Date: Mon, 13 Apr 2009 12:35:17 -0500

In case you missed this, IBM has just released a new function for z/OS 1.10
called Predictive Failure Analysis (PFA) which is now available.

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

This new feature is built upon the z/OS Health Checker infrastructure, and
is apparently the basis for future new capabilities.  Quoting from the
above, PFA will be extended over time..

The feature is available in the PTFs for APAR OA27165.

Brian

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




_
Netscape.  Just the Net You Need.

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


HSM Interval Migration and HOST

2009-04-13 Thread Lizette Koehler
I have been trying to find this answer in the DFSMShsm manuals.  And it is 
eluding me.

When I run Interval migration in HSM does it have to be on HOST A?  Or can I 
run it on any host?  How would I set that up?

I found the following documentation but I am not clear if this is what I want 
to do.  I really only want to run it once per hour on Host C.  The performance 
impact is minimal there.

If you want the space check to occur once per hour in each of n hosts, but at a 
different time after the hour in each host, issue the following patch. Set one 
field to the number of minutes after the hour when you want the space check to 
start, and set another field so that the sum of the two is 90. To start 
interval migration twice per hour requires two hosts. Issue the following 
patches to start space check on the primary host on the hour and start space 
check on the non-primary host at 30 minutes after the hour: 

Primary: PATCH .MGCB.+60 X’005A’ /* 90 minutes - default */ 
Non-primary: PATCH .MGCB.+62 X’001E’ /* 30 minutes after the */ 
 /* hour is the time to */ 
 /* do space check */ 
PATCH .MGCB.+60 X’003C’  /* 60 more minutes, to */ 
 /* take us to the middle */ 
 /* of the next hour */



Thanks.

Lizette

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


System z STP Enhancement: Retain Configurations Across PORs

2009-04-13 Thread Brian Peterson
Many customers who run STP do so in single-CEC configurations.  One
annoyance for me with such a configuration was the characteristic that if we
did a Power On Reset for some reason, the STP configuration was lost and had
to be reentered.

In late 2008, IBM addressed this restriction, and now it is possible to set
your single-CEC STP-configured system up such that the STP configuration is
retained across Power On Reset actions.

However, I was UNAWARE of the little check-box you must set to enable this
capability.  This check box action is described in the below TechDocs document:

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

Read this document, and check the box, if you want your single-CEC
STP-enabled server to retain its STP configuration across Power On Reset
actions - which might happen when you least expect it!

Brian

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


ICETOOL SPLICE

2009-04-13 Thread John Hric
I am trying to splice two 3540 byte files.  The keys are in  position 15
with a length of 10.   I have a similar splice working for 150 byte files
based on the examples for SPLICE.

Is there anything special needed for the larger record size?


//TOOLIN   DD  *

   COPY FROM(IT01) TO(OT01) USING(CTL1)

   COPY FROM(IT02) TO(OT02) USING(CTL2)

   SPLICE FROM(CONCAT) TO(OT04) WITH(1,14) ON(15,10,CH) -

 WITH(15,10) WITH(25,3513) -

 WITH(3539,1) WITH(3540,1) -

 WITHALL USING(CTL3)

/*

//CTL1CNTL DD *

   OUTREC FIELDS=(1:14X,15:5,10,25:110X,135:16X,151:3387X,

3539:C'B',3540:1X)

/*

//CTL2CNTL DD *

   OUTREC FIELDS=(1:1,14,15:15,10,25:25,3513,

3539:C'V',3540:3540,1)

/*

//CTL3CNTL DD *

   OUTFIL FNAMES=OT04,

   OMIT=(3539,1,CH,EQ,C'V'),

   OUTREC=(1,3538,3539,1,3540,1)





-- 
John Hric
Cleveland Oh
Reg 2, Zone 5b - 6a

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


Re: QSAM - Blocking logic defect for VB file?

2009-04-13 Thread Martin Kline
Johnny said:

One of our customers had a problem in their production batch jobs. One
COBOL program writes variable length records to a VB PS data set and after
smoothly running for ten years the program begun to generate VB files with
invalid RDWs as reported by DFSORT which is used to copy the files.  We are
at z/OS 1.9.

Did you recently update the run time libraries? Was the program recompiled 1) 
before the problem started or 2) before the problem resolved itself?

What do the FD and data descriptions specify? When the program calculates 
the length before writing, how does it communicate that information to QSAM?

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


Re: ICETOOL SPLICE

2009-04-13 Thread Frank Yaeger
John Hric wrote on 04/13/2009 11:01:51 AM:
 I am trying to splice two 3540 byte files.  The keys are in  position 15
 with a length of 10.   I have a similar splice working for 150 byte files
 based on the examples for SPLICE.

 Is there anything special needed for the larger record size?

 //TOOLIN   DD  *
COPY FROM(IT01) TO(OT01) USING(CTL1)
COPY FROM(IT02) TO(OT02) USING(CTL2)
SPLICE FROM(CONCAT) TO(OT04) WITH(1,14) ON(15,10,CH) -
  WITH(15,10) WITH(25,3513) -
  WITH(3539,1) WITH(3540,1) -
  WITHALL USING(CTL3)
 /*
 //CTL1CNTL DD *
OUTREC FIELDS=(1:14X,15:5,10,25:110X,135:16X,151:3387X,
 3539:C'B',3540:1X)
 /*
 //CTL2CNTL DD *
OUTREC FIELDS=(1:1,14,15:15,10,25:25,3513,
 3539:C'V',3540:3540,1)
 /*
 //CTL3CNTL DD *
OUTFIL FNAMES=OT04,
OMIT=(3539,1,CH,EQ,C'V'),
OUTREC=(1,3538,3539,1,3540,1)

No, there's nothing special needed for larger record sizes.
You didn't give any details of what you're trying to do or what the
problem is, but I can take a couple of educated guesses based on
what you did show:

1.  You say the keys are in position 15 with a length of 10, but in
CTL1CNTL, you have 15:5,10 - that would work if the key started in
5, not 15.  You probably want 15:15,10 like you have in CTL12CNTL.
If you moved the key from the wrong place in the IT01 records, then
you wouldn't get any matches.

2.  You are copying to two temporary files (OT01 and OT02) and
concatentating them for the SPLICE input.  This can be problematical
due to a system restriction that can cause loss of records as
documented in the second bullet at:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CA20/1.8.3.1?SHELF=DT=20060615185603CASE=

The recommended way to do this is to use ONE temporary MOD data set

//TOOLIN   DD  *
  COPY FROM(IT01) TO(T1) USING(CTL1)
  COPY FROM(IT02) TO(T1) USING(CTL2)
  SPLICE FROM(T1) TO(OT04) WITH(1,14) ON(15,10,CH) -
   ...

where T1 is something like:

//T1 DD DSN=T1,UNIT=SYSDA,SPACE=(CYL,(x,x)),DISP=(MOD,PASS)

If none of that helps, then feel free to send me an e-mail offline
(yae...@us.ibm.com)
with an example of the records in each input file and what you expect for
output, and)
an explanation of the rules you want to use for getting from input to
output, and I'll
help you code up the DFSORT/ICETOOL job correctly.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration

 = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/

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


Re: BDAM vs VSAM

2009-04-13 Thread Rick Fochtman
I don't know if BDAM was updated to use Format-1 CCWs, but IIRC, BDAM 
went Class-C on maintenance before the Format-1 CCW existed. This could 
be considered a definite drawback for any new application considering 
its use.


Edward Jaffe wrote:


Tom Russell wrote:


This does not match my experience at all. BDAM builds the CCW string
dynamically on every READ macro. The CCW string is then re-built as 
it is

translated Virtual to Real by EXCP. Decades ago VSAM RRDS used much less
CPU time per request than BDAM. I would be very surprised it that were
not still true, as I doubt BDAM has changed much since MVT.



I was under the impression that the traditional (i.e., pre-VSAM) 
access methods were updated so they now use Format-1 CCWs and EXCPVR. 
Was BSAM left behind when that conversion occurred?




--
Rick
--
Remember that if you’re not the lead dog, the view never changes.

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


Re: QSAM - Blocking logic defect for VB file?

2009-04-13 Thread Pinnacle
- Original Message - 
From: Johnny Luo johnny.xingkui@gmail.com

Newsgroups: bit.listserv.ibm-main
Sent: Monday, April 13, 2009 12:21 PM
Subject: QSAM - Blocking logic defect for VB file?



Hi,

One of our customers had a problem in their production batch jobs. One 
COBOL

program writes variable length records to a VB PS data set and after
smoothly running for ten years the program begun to generate VB files with
invalid RDWs as reported by DFSORT which is used to copy the files.  We 
are

at z/OS 1.9.

I first wrote a program to read the physical blocks and parsed each block
using BDW/RDW mechanism. It shows that there are 97 blocks which contain
invalid RDW(RDW4 or RDWLRECL)。No problem found in BDW. They just match 
the

physical length of corresponding block.

To find the real problem I decided to parse the blocks in a different way.
The COBOL program builds the records as following:

1. After RDW each record contains a 8-byte identifier string 'BGLGLGP ';
2. 120 bytes from identifier string is a two-bytes length field which
contains the length of the variable data of the record;
3. Then comes the variable length part.

So I use the string ''BGLGLGP ' as delimiter to separate each record and
then find its 'real' RDW value in the 4-byte area just before the 
identifier

string.  I also use the two-byte length field set by user program to
calculate the supposed RDW value.

This time the result is more enlightening. All 97 'bad' blocks are in the
same pattern: (the following is simplified just to illustrate)

-
| BDW  | RDW1 |   REC1 | RDW2 | REC2  |
-
1. BDW matches the actual length of the block;
2. RDW1 and RDW2 all match the 'should-be' RDW value calculated from 
length

field set by application program;

The problem lies in the actual record length.  For REC1, its actual length
is shorter or longer than RDW1 indicates!

When DFSORT or other application like ISPF tries to parse the block via 
RDW,

it found no problem with record1 cause the value of RDW1 is valid. But it
will get the wrong start address of record2 via RDW1 cause the actual 
length

of REC1 is not as RDW1 indicates.  That's means it will select the wrong
area as RDW2 and its value is unpredictable.  Thus the so-called 'invalid
rdw'.

How does this happen? I can only think of one situation, that is, when 
QSAM
is building the block.  After moving record1 into the block, record2 
should

be placed right after record1. If for some reason QSAM failed to do so,
record2 will overlay part of record1 or be placed far behind record1. 
That

will generate a 'bad' block exactly as what we saw in this case.

To make things more complicated, the customer found one of their channel
paths could not be vary online when they tried to re-IPL the system. So 
they

temporarily discard the use of that path and then suddenly the problem
disappears.

Now the customer believe the problem is caused by that channel path and 
they

have reported the problem to IBM.

For me it's hard to accept it cause I cannot see the relationship. Write
operation does involve the interacion with channel subsystem but from my
limited knowledge after QSAM finished the building of the block all the 
left
operations are at block level and will not touch the inner structure of 
the
block.  It's nearly impossible for them to generate a 'bad' block exactly 
as

we saw in this specific case even if truncating or overlay occurs.  So I
still believe the cause of the problem is that QSAM somehow failed to 
build

the block right.

Any one can give me some hints?


--


Johnny,

If you're getting corrupted RDW's, don't waste time here, open a PMR 
immediately.


Regards,
Tom Conley 


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


Re: BDAM vs VSAM

2009-04-13 Thread Patrick O'Keefe
On Mon, 13 Apr 2009 14:44:23 -0500, Rick Fochtman 
rfocht...@ync.net wrote:

... IIRC, BDAM went Class-C on maintenance before the Format-1 
CCW existed. ...

Ok.  I have a faulty memory.  Please 'splain me again Class-C.

I vaguely remember back when IBM was going OCO that they came
up with some support classes that I think of as

Class-A   the operating system code maybe?
Class-B   fully supported Program Products
Class-C   SE-supported
Class-D   unsupported FDPs 

I don't remember any access method code being anything but
Class-A so I suspect that is not what what you were refering to 
(or that my faulty memory has totally broken down - always a
reaonable possibility).

Pat O'Keefe 

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


Re: ICETOOL SPLICE

2009-04-13 Thread John Hric
Sorry about the skipped details.

IT01 is a 150 byte file with the key in position 5
IT02 is a 3540 byte file with the key in position 15

Basically just taking the key from IT01 selecting matching records from IT02.

Aside from adding the 'V' to position 3539, the entire IT02 record is
being copied intact.
All files are ( and were) cataloged.  However CONCAT has now been made
a single file.

The WITH parmameters have been simplified a bit but should be
essentially the same.

OT01 is lining up both in the key field and the OMIT field.  It runs
clean with a 0 RC.  With the Omit turned on there is nothing in OT04.
With OMIT off it is picking up my small sample matching key and every
duplicate key on the IT02 file.

Trying to get it working before with small samples before throwing it
at the haystack.

Not sure if all of your email addy came through.  Mine should show up
on the gmail group profile.  and below.

Thanks
John

hricjd

gmail.com

IT01
=COLS  +1+2+3+4+5+6---
01  128 2413080005 3QCLN 120746130800712203QCLN99
02  128 4613080002 3QCLN 120746130800712203QCLN99
03  128 4655080005 3QCLN 120746130800712203QCLN99
04  128 4682787005 JFSAV 12074682787071224JFSAV084480

IT02
=COLS  +1+2+3+4+5+6+7--
64  11MROO2038161025   20381612025   02421
65  11MROO2042985046   20429852046   05745
66  11MRII4655080005   19417280230   00971
67  3131  4655080005   1984Y43491   Y3572Y25060
68  11MRII5558791001   19417280230   00971

OT01
=COLS  +1+2+3+4+5+
034655080005
044682787005
054773829077
74  11MROO2042985046   20429852046   05745
75  11MRII4655080005   19417280230   00971
76  3131  4655080005   1984Y43491   Y357

//OT01 DD DSN=FCAT.KS7.ULRL.PROFDX.M2008.S11R,
//UNIT=(SYSDA,6),
//DISP=MOD,
//SPACE=(3540,(5,5),RLSE),AVGREC=K,
//DCB=(MODLDSCB,RECFM=FB,LRECL=3540,BLKSIZE=0)
//CONCAT   DD DSN=FCAT.KS7.ULRL.PROFDX.M2008.S11R,DISP=OLD
//OT04 DD  DSN=FCAT.KS7.ULRL.PROFDX.M20X8.OUT4,
//DISP=OLD,
// UNIT=(SYSDA,20),
// SPACE=(3540,(100,250),RLSE),AVGREC=K,
//DCB=(MODLDSCB,RECFM=FB,LRECL=3540,BLKSIZE=0)

//TOOLIN   DD  *
   COPY FROM(IT01) TO(OT01) USING(CTL1)
   COPY FROM(IT02) TO(OT01) USING(CTL2)
   SPLICE FROM(CONCAT) TO(OT04) WITH(1,14) ON(15,10,CH) -
 WITH(15,10) WITH(25,3514) -
 WITH(3539,1) WITH(3540,1) -
 WITHALL USING(CTL3)
/*
//CTL1CNTL DD *
   OUTREC FIELDS=(1:14X,15:5,10,25:3514X,3539:C'B',3540:1X)
/*
//CTL2CNTL DD *
   OUTREC FIELDS=(1:1,14,15:15,10,25:25,3514,3539:C'V',3540:3540,1)
/*
//CTL3CNTL DD *
   OUTFIL FNAMES=OT04, -
   OMIT=(3538,1,CH,EQ,C'V'),  -
   OUTREC=(1,3538,3539,1,3540,1)

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


OPERLOG issues 2 of 5 systems missing

2009-04-13 Thread Lizette Koehler
We are using OPERLOG for our SYSLOG.  It seems that 2 of 5 systems are not 
writing to OPERLOG.  Are there any commands I can use to get the OPERLOG 
structure working again?

I did a D XCF,STR,STRNAME=OPERLOG and can see 3 of the 5 systems connected.  I 
am trying to see when the other two quit.  Other than an IPL, is there anyway 
to reconnect the OPERLOGs?

Lizette

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


Re: OPERLOG issues 2 of 5 systems missing

2009-04-13 Thread Kevin Mckenzie
Try issuing the command 'V OPERLOG,HARDCPY' on the two systems that aren't 
writing to OPERLOG.

You may need to forcibly disconnect those logstreams from the structure, 
if they're what's broken.  Try issuing the command 'd 
logger,l,strname=OPERLOG' and 'D LOGGER,CONN,LSNAME=logstream name,D'
---
Kevin McKenzie

External Phone: 845-435-8282, Tie-line: 8-295-8282
z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 



Lizette Koehler stars...@mindspring.com 
Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
04/13/2009 04:45 PM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu


To
IBM-MAIN@bama.ua.edu
cc

Subject
OPERLOG issues 2 of 5 systems missing






We are using OPERLOG for our SYSLOG.  It seems that 2 of 5 systems are not 
writing to OPERLOG.  Are there any commands I can use to get the OPERLOG 
structure working again?

I did a D XCF,STR,STRNAME=OPERLOG and can see 3 of the 5 systems 
connected.  I am trying to see when the other two quit.  Other than an 
IPL, is there anyway to reconnect the OPERLOGs?

Lizette

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

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


Re: OPERLOG issues 2 of 5 systems missing

2009-04-13 Thread Jerry Whitteridge
Look at the vary hardcpy commands

Example 1

 

To include all operator commands, responses, and status displays (except

dynamic status displays) in the hardcopy message set, enter:

 

  V ,HARDCPY,STCMDS

 

Example 2

 

To have the hardcopy message set recorded on the system log, enter:

 

  V SYSLOG,HARDCPY

 

Example 3

 

To add routing codes 11, 12, 13, 17, and 44 to the routing codes already

defined for the hardcopy message set, enter:

 

  V ,HARDCPY,AROUT=(11-13,17,44)

 

Example 4

 

To have the hardcopy message set recorded on the operations log, enter:

 

  V OPERLOG,HARDCPY


Jerry Whitteridge
Mainframe Engineering
Safeway Inc
925 951 4184
jerry.whitteri...@safeway.com
If everything seems under control, you're just not going fast enough. 
 

 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler
 Sent: Monday, April 13, 2009 1:46 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: OPERLOG issues 2 of 5 systems missing
 
 We are using OPERLOG for our SYSLOG.  It seems that 2 of 5 
 systems are not writing to OPERLOG.  Are there any commands I 
 can use to get the OPERLOG structure working again?
 
 I did a D XCF,STR,STRNAME=OPERLOG and can see 3 of the 5 
 systems connected.  I am trying to see when the other two 
 quit.  Other than an IPL, is there anyway to reconnect the OPERLOGs?
 
 Lizette
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
 
 

Email Firewall made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

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


Re: OPERLOG issues 2 of 5 systems missing

2009-04-13 Thread Lizette Koehler
Absolutely Brilliant and way too easy.

Thanks

Lizette




Try issuing the command 'V OPERLOG,HARDCPY' on the two systems that aren't 
writing to OPERLOG.

You may need to forcibly disconnect those logstreams from the structure, 
if they're what's broken.  Try issuing the command 'd 
logger,l,strname=OPERLOG' and 'D LOGGER,CONN,LSNAME=logstream name,D'
---
Kevin McKenzie

External Phone: 845-435-8282, Tie-line: 8-295-8282
z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 



Lizette Koehler stars...@mindspring.com 
Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
04/13/2009 04:45 PM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu


To
IBM-MAIN@bama.ua.edu
cc

Subject
OPERLOG issues 2 of 5 systems missing






We are using OPERLOG for our SYSLOG.  It seems that 2 of 5 systems are not 
writing to OPERLOG.  Are there any commands I can use to get the OPERLOG 
structure working again?

I did a D XCF,STR,STRNAME=OPERLOG and can see 3 of the 5 systems 
connected.  I am trying to see when the other two quit.  Other than an 
IPL, is there anyway to reconnect the OPERLOGs?

Lizette


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


Re: RECORD OUT OF SEQUENCE in UCAT

2009-04-13 Thread Amerigo Baldassarri
Hello Juan,

It would appear from the message that this catalog needs to be recovered. Have 
a look at a product called Catalog RecoveryPlus from www.mainstar.com

Regards

Amerigo 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Juan Vicente RodrÃguez Puertas
Sent: Monday, April 13, 2009 10:10 PM
To: IBM-MAIN@bama.ua.edu
Subject: RECORD OUT OF SEQUENCE in UCAT

Hi,

We got the following erros when we try to export a user catalog.

   EXPORT CAT.USUARIO.MUTUA OUTFILE(CINTASA) 
TEMPORARY  
IDC3302I  ACTION ERROR ON CAT.USUARIO.MUTUA 
IDC3314I **RECORD OUT OF SEQUENCE - KEY 
FOLLOWS:
00  C4C5E2F0 F14BC1E3 F1F04BE3 F5F44BE2   E8E2D6E4 E3F14040 
40404040 4040404
20  40404040 40404040 40404040 00   

IDC3302I  ACTION ERROR ON CAT.USUARIO.MUTUA 
IDC3308I ** DUPLICATE RECORD - KEY FOLLOWS: 
00  C4C5E2F0 F14BC1E3 F1F04BE3 F5F44BE2   E8E2D6E4 E3F14040 
40404040 4040404
20  40404040 40404040 40404040 00   

IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 
12  

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 
12  

We were searching IBM-Main archives and we found this post

Item#   Date  Time   Lines Subject 
034704 2006-06-26 14:38   95   Record out of sequence error on UCAT 

Unfortunaly nobody answered to it.

Is there a way to delete the records causing the error?

Could someone help us?

TIA

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

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


Re: ICETOOL SPLICE

2009-04-13 Thread Frank Yaeger
John Hric hri...@gmail.com wrote on 04/13/2009 01:39:41 PM:
 ...
 OT01 is lining up both in the key field and the OMIT field.  It runs
 clean with a 0 RC.  With the Omit turned on there is nothing in OT04.
 With OMIT off it is picking up my small sample matching key and every
 duplicate key on the IT02 file.

You are using 3538 for the OMIT, but you put the 'B' and 'V' in 3539.
And even if you did have 3539 for the OMIT, you would be omitting
all of the matching records since they would have 'V' in them due
to your WITH(3539,1) operand.

I believe this DFSORT/ICETOOL job will give you what you want.
Note that you don't need the CONCAT DD.

//S1   EXEC  PGM=ICETOOL
//TOOLMSG   DD  SYSOUT=*
//DFSMSGDD  SYSOUT=*
//IT01 DD DSN=...  input file (FB/150).
//IT02 DD DSN=...  input file (FB/3540)
//OT01 DD DSN=FCAT.KS7.ULRL.PROFDX.M2008.S11R,
//UNIT=(SYSDA,6),
//DISP=MOD,
//SPACE=(3540,(5,5),RLSE),AVGREC=K,
//DCB=(MODLDSCB,RECFM=FB,LRECL=3540,BLKSIZE=0)
//OT04 DD  DSN=FCAT.KS7.ULRL.PROFDX.M20X8.OUT4,
//DISP=OLD,.
// UNIT=(SYSDA,20),
// SPACE=(3540,(100,250),RLSE),AVGREC=K,
//DCB=(MODLDSCB,RECFM=FB,LRECL=3540,BLKSIZE=0)
//TOOLIN   DD  *
COPY FROM(IT01) TO(OT01) USING(CTL1),
COPY FROM(IT02) TO(OT01) USING(CTL2),
SPLICE FROM(OT01) TO(OT04) ON(15,10,CH) WITHALL -
  WITH(1,3541) USING(CTL3)
/*
//CTL1CNTL DD *
  INREC BUILD=(15:5,10,3541:C'BB')
/*
//CTL2CNTL DD *
  INREC OVERLAY=(3541:C'VV')
/*
//CTL3CNTL DD *
   OUTFIL FNAMES=OT04, -
   INCLUDE=(3541,2,CH,EQ,C'VB'),  -,
   BUILD=(1,3540)
/*

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration

 = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/

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


Re: CF Status of Transitioning

2009-04-13 Thread Skip Robinson
The recommended 'ideal' method to migrate from one sysplex environment to
another is completely dynamic, using SETXCF commands to empty an old CF by
rebuilding all of its structures in either a CF that stays connected before
and after the migration, or in a new CF that is already connected before
the migration. We did some migrations last year where neither option was
possible:

-- Push/pull hardware such that all old CFs are replaced by new ones in a
single outage
-- Relocate systems and (logical) CFs to another data center beyond cable
length limits

In such cases you come up with a set of brand new CFs. No matter how well
you prepare, you will still get some structures with one foot in the old
world and one the new. XCF wants to touch the old CF to clean up properly.
If that's not possible, just create a new CFRM policy that contains no
trace of the old CF. That is, the CF definition itself is gone, and all
PREFLISTs no longer contain any reference to the old CF. That policy should
implement with no problem, and structure displays will now show clean.

As long as your sysplexes are functioning with all structures active
somewhere, I'd say you did it all properly.

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com


   
 Michael Hall  
 mhha...@attgloba 
 L.NET To 
 Sent by: IBM  IBM-MAIN@bama.ua.edu
 Mainframe  cc 
 Discussion List   
 ibm-m...@bama.ua Subject 
 .edu CF Status of Transitioning  
   
   
 04/12/2009 10:20  
 PM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 ibm-m...@bama.ua 
   .edu   
   
   




List,

We migrated an LPAR from one physical box to another, and one CF to
another.
Displaying a structure shows one structure allocated and one in transition.
I
would like to get rid of the in transition messages since we are not
planning
to use that CF on this system and currently have no connection to it.

I am wondering if there was something that we did improperly when we
brought down the old LPAR.

Our current CF policy has old and new CF addresses in it.

Thanks for any help or anyone can point me to a manual that would answer
these questions.

Our structure status looks as follows:

 D XCF,STR,STRNM=DSNPB0A_GBP0
 MR000 BP1D 09083 10:39:51.15 DB2ADM   0090  IXC360I
10.39.51  DISPLAY XCF 504
 LR504 0090  STRNAME:
DSNPB0A_GBP0
 DR504 0090   STATUS: ALLOCATED
 DR504 0090   POLICY
INFORMATION:
 DR504 0090POLICY SIZE:
64000 K
 DR504 0090POLICY INITSIZE:
16000 K
 DR504 0090POLICY MINSIZE :
0 K
 DR504 0090FULLTHRESHOLD  :
80
 DR504 0090ALLOWAUTOALT   :
NO
 DR504 0090REBUILD PERCENT:
1
 DR504 0090DUPLEX :
ENABLED
 DR504 0090ALLOWREALLOCATE:
YES
 DR504 0090PREFERENCE LIST:
BA01C1
BAC1C1   BCC1C5   BCC2C5
 DR504 0090ENFORCEORDER   :
NO
 DR504 0090EXCLUSION LIST
IS EMPTY
 DR504 0090
 DR 

Re: BDAM vs VSAM

2009-04-13 Thread Rick Fochtman
IIRC, CLASS-C Maintenance meant that old faults would be repaired but 
that there would be no further updates to account for hardware or OS 
upgrades.


Patrick O'Keefe wrote:

On Mon, 13 Apr 2009 14:44:23 -0500, Rick Fochtman 
rfocht...@ync.net wrote:


 

... IIRC, BDAM went Class-C on maintenance before the Format-1 
CCW existed. ...
   



Ok.  I have a faulty memory.  Please 'splain me again Class-C.

I vaguely remember back when IBM was going OCO that they came
up with some support classes that I think of as

Class-A   the operating system code maybe?
Class-B   fully supported Program Products
Class-C   SE-supported
Class-D   unsupported FDPs 


I don't remember any access method code being anything but
Class-A so I suspect that is not what what you were refering to 
(or that my faulty memory has totally broken down - always a

reaonable possibility).

Pat O'Keefe 


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

 



--
Rick
--
Remember that if you're not the lead dog, the view never changes.



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


Re: QSAM - Blocking logic defect for VB file?

2009-04-13 Thread Johnny Luo
Tom,

Thanks for the help.

Serveral PMRs have already been opened against various components.
Obviously the problem has nothing to do with the application program itself.

I'm just wondering which part goes wrong. PMR has not been closed and the
customer now opened another PMR concering the channel path problem.






2009/4/14 Pinnacle pinnc...@rochester.rr.com

 - Original Message - From: Johnny Luo 
 johnny.xingkui@gmail.com
 Newsgroups: bit.listserv.ibm-main
 Sent: Monday, April 13, 2009 12:21 PM
 Subject: QSAM - Blocking logic defect for VB file?







 Johnny,

 If you're getting corrupted RDW's, don't waste time here, open a PMR
 immediately.

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




-- 
Best Regards,
Johnny Luo

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


Re: BDAM vs VSAM

2009-04-13 Thread John McKown
On Mon, 13 Apr 2009, Rick Fochtman wrote:

 IIRC, CLASS-C Maintenance meant that old faults would be repaired but 
 that there would be no further updates to account for hardware or OS 
 upgrades.
 

However, given the 3390 DASD architecture forever mantra of z/OS, does
this really matter? Or does it mean that, like BTAM, if something in z/OS
changes in such a way as to cause BDAM to fail, then tough buns (as they
say in the baking industry). What sort of change in z/OS could cause BDAM
to fail to work? Ignoring EAV. EAV seems to be basically VSAM only type
support. Of course, VSAM could be used to replace every other access
method except for PDS. Given VSAM KSDS (keyed), ESDS (sequential), RRDS
(numbered), VRRDS (variable numbered), and LINEAR (UNIX filesystems and
other), is there something that could NOT be rearchitected to use VSAM
(ignore cost)?  I'll ignore some really clever BDAM code that I learned
back under OS/MVT - it was really wild, using hardware keys and polling
the existance of specific hardware keys to do message passing between
systems.

-- 
Trying to write with a pencil that is dull is pointless.

Maranatha!
John McKown

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


Re: BDAM vs VSAM

2009-04-13 Thread Edward Jaffe

Rick Fochtman wrote:
I don't know if BDAM was updated to use Format-1 CCWs, but IIRC, BDAM 
went Class-C on maintenance before the Format-1 CCW existed.


In which publication/URL are these maintenance classes documented? Which 
publication/URL lists the various access methods and the class of 
maintenance assigned to them?


This could be considered a definite drawback for any new application 
considering its use.


If true. So far, I've heard absolutely NOTHING other than what I would 
classify as rumor. I would like to see something concrete that 
substantiates the original premise of this thread...


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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


Re: z/OS 1.10 Enhancement: Predictive Failure Analysis

2009-04-13 Thread Timothy Sipples
At the risk of straying way off topic, in the 2010 sequel HAL's behavior
was well explained: HAL had evil programmers, quite simply. The crew's
government superiors instructed HAL, among other things, to lie to the
crew. And HAL did exactly as he was told, perfectly.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Based in Tokyo, Serving IBM Japan / Asia-Pacific
E-Mail: timothy.sipp...@us.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html