Re: Shop zSeries Ordering Issues
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Schwarz, Barry A Strange, I could have sworn you were one of the vocal dissenters when IBM did away with JOBCAT and STEPCAT. Not all progress is in the forward direction. I think that was Ed Gould -jc- -- 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
SMS-releasing unused space
Hello, in order to prevent releasing of unused space for some datasets, I allocated it yesterday with MC that has Partial release parameter set to 'No'. However, today when I look at some of those datasets, they look like the space was first released (primary extent is 1 cyl, allocated was 200), and then as the data was loaded it took 11 secondary extents. This is exactly what I wanted to prevent. Can someone explain to me how this happened? General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 221 Storage class . . . : MEDIUM Allocated extents . : 12 Volume serial . . . : SSP122 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 204 Record format . . . : FB Used extents . . . : 12 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 1 Secondary cylinders : 20 Data set name type :SMS Compressible : NO Regards, Natasa -- 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
SV: SDSF REXX problem
For those eventually doing the same misstake,
I was sent a solution/correction by a kind guy:
(It worked!)
Hi Thomas
during the loop, the NP ? command overwrites the TOKEN.I variables from the
ST command.
Add a (PREFIX R) statement to the ISFACT like
Address SDSF ISFACT ST TOKEN('token.i') PARM(NP ?) (PREFIX R)
and all the variables from the ? panel will be prefixed by R.
The dsname var is then rdsname means
Do j = 1 To rdsname.0
Say rdsname.j
End
Good luck
Stefan
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] För Thomas Berg
Skickat: den 30 april 2008 14:37
Till: IBM-MAIN@BAMA.UA.EDU
Ämne: SDSF REXX problem
Hi!
I have a problem when running SDSF REXX commands.
When looping the returned isfrows after ISFEXEC ST command, the second ISFACT
returns INVALID COMMAND (and rc = 0).
I can't see why.
The REXX:
/* REXX */ Trace R
x = Isfcalls('ON')
isfprefix = 'S000TBE5'
isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' ,
'SYSNAME WORKLOAD CPU TRANACT SRVCLS SRVCLASS ACTSYS' ,
'SYSAFF TOKEN PRTDEST'
Address SDSF 'ISFEXEC ST (ALTERNATE)'
isfcols2 = ,
'DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME'
Do i = 1 To isfrows
Address SDSF ISFACT ST TOKEN('token.i') ,
'PARM(NP ?)'
Trace N
Say rc
Say isfmsg
Do j = 1 To isfmsg2.0
Say isfmsg2.j
End
Do j = 1 To dsname.0
Say dsname.j
End
Trace R
End
x = Isfcalls('OFF')
Exit 0
The output:
2 *-* x = Isfcalls('ON')
0
3 *-* isfprefix = 'S000TBE5'
S000TBE5
4 *-* isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' , 'SYSNAME
WORKLOAD CPU TRANACT SRVC
LS SRVCLASS ACTSYS' , 'SYSAFF TOKEN PRTDEST'
JNAME JOBID OWNERID JCLASS POS STATUS SYSNAME WORKLOAD
CPU TRANACT SRVCLS SRVCLASS ACTSYS SYSAFF TOKEN PRTDEST
7 *-* Address SDSF 'ISFEXEC ST (ALTERNATE)'
ISFEXEC ST (ALTERNATE)
8 *-* isfcols2 = ,
'DDNAME STEPN PROCS DSID OCLASS RE
CCNT BYTECNT DSNAME'
DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME
11 *-* Do i = 1 To isfrows
1
2
12 *-* Address SDSF ISFACT ST TOKEN('token.i') ,
'PARM(NP ?)'
ISFACT ST
TOKEN('6jkSNicbJpKic/D1m8LEQNp38PrbwuNA6yKmVtAgRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPDUEDj+XPw4rJGQOP4fPDrExO
CEgEGCBQ=') PARM(NP ?)
14 *-* Trace N
0
ISF754I Command 'PREFIX S000TBE5' generated from associated variable
ISFPREFIX.
S000TBE.S000TBE5.JOB01687.D002.JESMSGLG
S000TBE.S000TBE5.JOB01687.D003.JESJCL
S000TBE.S000TBE5.JOB01687.D004.JESYSMSG
S000TBE.S000TBE5.JOB01687.D104.?
S000TBE.S000TBE5.JOB01687.D108.?
S000TBE.S000TBE5.JOB01687.D111.?
27 *-* End
11 *-* Do i = 1 To isfrows
12 *-* Address SDSF ISFACT ST TOKEN('token.i') ,
'PARM(NP ?)'
ISFACT ST
TOKEN('6jkSNicbJpKic/D1esLEQNp38PrbwuNA67SCN30gRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPAUEDj+XPw4kpGQOP4c/DhUsT
K4vH1c+PDVMPi8fh849MUliAAAQYbNapb/Q768OPGPQ==') PARM(NP ?)
14 *-* Trace N
0
INVALID COMMAND
ISF754I Command 'PREFIX S000TBE5' generated from associated variable
ISFPREFIX.
S000TBE.S000TBE5.JOB01687.D002.JESMSGLG
S000TBE.S000TBE5.JOB01687.D003.JESJCL
S000TBE.S000TBE5.JOB01687.D004.JESYSMSG
S000TBE.S000TBE5.JOB01687.D104.?
S000TBE.S000TBE5.JOB01687.D108.?
S000TBE.S000TBE5.JOB01687.D111.?
27 *-* End
11 *-* Do i = 1 To isfrows
29 *-* x = Isfcalls('OFF')
FW: VSAM / COBOL question - redux (fwd)
Well, if ya'll remember, we've had a spate of COBOL File Status codes of 97 since we split our z/OS image in two. This occurs when the file is open for OUTPUT on one image and a COBOL program opens the same file for INPUT on the other image. Well, we have another File Status. This time with a code of 90. The diagnostics for that are not as obvious, but the question is the same. Is this do to the LPAR split? If so, how do we fix it. I don't know off hand. None, or maybe only few, of our COBOL program use the extended FILE STATUS phrase to get VSAM codes. This particular program does not. The only IEC161I messages that I see in the job are the ones which normally have a file status of 97, not 90. Any preliminary help before I tell the programmer to change the program so that it displays the VSAM file status codes as well? Everybody knows what the response to that will be: We never had to do that in the past!!! sigh. I hate this splitting of the image in twain. It is rooting out all sorts of bugs. -- 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: allowuserkeycsa
We've been using the default of YES up to z/OS 1.8, but will now take the default of NO for z/OS 1.9. Shouldn't be any problem, as we will discover any issues when rolling out through various systems. So far we've discovered a bug in our Sysprog sysplex with a BMC DB2 utility, but they've released a fix for that now. You can dynamically switch from NO to YES anyway, should it cause issues. -- 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: SMS-releasing unused space
Natasa, Hello, in order to prevent releasing of unused space for some datasets, I allocated it yesterday with MC that has Partial release parameter set to 'No'. However, today when I look at some of those datasets, they look like the space was first released (primary extent is 1 cyl, allocated was 200), and then as the data was loaded it took 11 secondary extents. This is exactly what I wanted to prevent. Can someone explain to me how this happened? General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 221 Storage class . . . : MEDIUM Allocated extents . : 12 Volume serial . . . : SSP122 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 204 Record format . . . : FB Used extents . . . : 12 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 1 Secondary cylinders : 20 Data set name type :SMS Compressible : NO Regards, Natasa -- 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 The fact that the allocated cylinders is greater than the used cylinders (221 204) leads me to believe that space was not released from the dataset (allocated cylinders would equal used cylinders). The 1st extent is just the size of the first extent and not the primary space allocation amount. Each allocation can be up to five extents, even more if you are using the storage space constraint relief features of SMS. I recommend you look at the fragmentation index on your volume(s) and run some defrags. Regards, 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: DFSMSRMM Server/Client setup
Mark, Although we would expect a client and its server to not be sharing the TCDB, theoretically you could do that. However, since one main driver for client/server is that there is no shared DASD, usuallly there is no other DASD sharing. RMM has no default PORT, that is a mandatory operand within the CLIENT and SERVER operands on the OPTION command in parmlib. Mike Wood RMM Development On Fri, 2 May 2008 13:21:29 -0400, Mark Pace [EMAIL PROTECTED] wrote: What happens with OAM and the VOLCAT when you run in a Client/Server configuration? I'm currently running 2 LPARs sharing the VOLCAT and the RMM files. Will I still need to share the VOLCAT between the 2 systems? I've also been unable to find the default port that RMM will use on TCPIP. -- Mark Pace Mainline Information Systems -- 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: Heads Up: WSC Flash - Bad PTFs
On Mon, 5 May 2008 20:29:06 -0700, Edward Jaffe wrote: Paul Gilmartin wrote: I wonder whether most of us, even Ed. J are now convinced of the disadvantages of IEHIBALL, ... ITYM Ed Finnell ... Oops. Sorry. CRS. Or my own deficient IEBIBALL. It was David Jousma who sneered at those of us who raised the issue: http://bama.ua.edu/cgi-bin/wa?A2=ind0805L=ibm-mainP=19889 ... and the Flash remains an image rather than text: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10644 I've seen the problem elsewhere. The process requirements for updating web page content override the urgency of the update. -- 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: SMS-releasing unused space
On Tue, 6 May 2008 08:25:42 -0400, John Kington wrote: Natasa wrote: Hello, in order to prevent releasing of unused space for some datasets, I allocated it yesterday with MC that has Partial release parameter set to 'No'. However, today when I look at some of those datasets, they look like the space was first released (primary extent is 1 cyl, allocated was 200), and then as the data was loaded it took 11 secondary extents. This is exactly what I wanted to prevent. Can someone explain to me how this happened? General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 221 Storage class . . . : MEDIUM Allocated extents . : 12 Volume serial . . . : SSP122 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 204 Record format . . . : FB Used extents . . . : 12 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 1 Secondary cylinders : 20 Data set name type :SMS Compressible : NO The fact that the allocated cylinders is greater than the used cylinders (221 204) leads me to believe that space was not released from the dataset (allocated cylinders would equal used cylinders). The 1st extent is just the size of the first extent and not the primary space allocation amount. Each allocation can be up to five extents, even more if you are using the storage space constraint relief features of SMS. I recommend you look at the fragmentation index on your volume(s) and run some defrags. I think it's unlikely that the volume is so fragmented that the first extent allocated was only 1 cylinder, but that he was able to obtain a total of 220 cylinders in 12 extents. It is especially unlikely considering that the secondary allocation is 20 cylinders. It is more likely that something caused the primary allocation to be 1 cylinder with 11 secondary allocations of 20 cylinders each. There is not enough information to guess how this might have happened. -- Tom Marchant -- 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: DFSMSRMM Server/Client setup
Thanks, Mike - I don't have to, or want to share the TCDB any longer, I just wanted to be sure that it would continue to work. Where can I find documentation on setting up the OMVS segment for RMM? I didn't find it in the Implementation guide. On Tue, May 6, 2008 at 8:29 AM, Mike Wood [EMAIL PROTECTED] wrote: Mark, Although we would expect a client and its server to not be sharing the TCDB, theoretically you could do that. However, since one main driver for client/server is that there is no shared DASD, usuallly there is no other DASD sharing. RMM has no default PORT, that is a mandatory operand within the CLIENT and SERVER operands on the OPTION command in parmlib. Mike Wood RMM Development On Fri, 2 May 2008 13:21:29 -0400, Mark Pace [EMAIL PROTECTED] wrote: What happens with OAM and the VOLCAT when you run in a Client/Server configuration? I'm currently running 2 LPARs sharing the VOLCAT and the RMM files. Will I still need to share the VOLCAT between the 2 systems? I've also been unable to find the default port that RMM will use on TCPIP. -- Mark Pace Mainline Information Systems -- 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 -- Mark Pace Mainline Information Systems -- 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: DFSMSRMM Server/Client setup
Mark, You are correct we do not document that requirement within the rmm pubs. The requirement is here http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/f1a1b370/1.2.11.1? SHELF=EZ2ZO10J.bksDT=20070604150102 in the Comm Svr: IP Configuration Guide. Mike Wood RMM Development On Mon, 5 May 2008 11:20:40 -0400, Mark Pace [EMAIL PROTECTED] wrote: I also can not find in the Implementation Guide anything about the OMVS segment that is required. Is that documented elsewhere? -- Mark Pace Mainline Information Systems -- 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: Heads Up: WSC Flash - Bad PTFs
Sneer might be a bit strong. Rather than 10 posts about how it couldn't be cut/paste, I just typed it up once for everyone, knowing that webpage don't get updated very quick ___ Dave Jousma Assistant Vice President Mainframe Services [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Tuesday, May 06, 2008 8:34 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Heads Up: WSC Flash - Bad PTFs On Mon, 5 May 2008 20:29:06 -0700, Edward Jaffe wrote: Paul Gilmartin wrote: I wonder whether most of us, even Ed. J are now convinced of the disadvantages of IEHIBALL, ... ITYM Ed Finnell ... Oops. Sorry. CRS. Or my own deficient IEBIBALL. It was David Jousma who sneered at those of us who raised the issue: http://bama.ua.edu/cgi-bin/wa?A2=ind0805L=ibm-mainP=19889 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS-releasing unused space
Natasa, in order to prevent releasing of unused space for some datasets, I allocated it yesterday with MC that has Partial release parameter set to 'No'. However, today when I look at some of those datasets, they look like the space was first released (primary extent is 1 cyl, allocated was 200), and then as the data was loaded it took 11 secondary extents. This is exactly what I wanted to prevent. Can someone explain to me how this happened? Is it possible that the data set was migrated/recalled before loading? From DFSMShsm Storage Administration Guide: 2. The PARTIAL RELEASE attribute does not apply to normal migration and recall processing. Related reading: For more information about migration and recall space allocation, see Additional Space Management during Migration and Recall When DFSMShsm Is the Data Mover in topic 2.1.21.7. Regards, Hermann -- 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: Heads Up: WSC Flash - Bad PTFs
snipped Sneer might be a bit strong. Rather than 10 posts about how it couldn't be cut/paste, I just typed it up once for everyone, knowing that webpage don't get updated very quick end And you used less energy and bandwidth. One kudos to you. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John Well, if ya'll remember, we've had a spate of COBOL File Status codes of 97 since we split our z/OS image in two. This occurs when the file is open for OUTPUT on one image and a COBOL program opens the same file for INPUT on the other image. Well, we have another File Status. This time with a code of 90. The diagnostics for that are not as obvious, but the question is the same. Is this do to the LPAR split? If so, how do we fix it. I don't know off hand. None, or maybe only few, of our COBOL program use the extended FILE STATUS phrase to get VSAM codes. This particular program does not. The only IEC161I messages that I see in the job are the ones which normally have a file status of 97, not 90. Any preliminary help before I tell the programmer to change the program so that it displays the VSAM file status codes as well? Everybody knows what the response to that will be: We never had to do that in the past!!! sigh. I hate this splitting of the image in twain. It is rooting out all sorts of bugs. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/6.1. 8.9.1 And http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG32/1.13 .4.5 (In that order.) -jc- -- 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
Service Unit to CPU minute conversion
I have a request from management to give them the number of CPU minutes used for a certain time period per application. I have the numbers for numbers of service units for each period and application, but I need to know what conversion factor I can use to convert this to CPU minutes? Is there a manual that walks me through this process? Also, we are on a 2064-102. which I would think would be a factor in the conversion process. I seem to remember that service units apply based on a machine type? I looked through the archives and did not see anything that specifically addressed this, so I figured I'd ask the group. 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: SMS-releasing unused space
Tom, On Tue, 6 May 2008 08:25:42 -0400, John Kington wrote: Natasa wrote: Hello, in order to prevent releasing of unused space for some datasets, I allocated it yesterday with MC that has Partial release parameter set to 'No'. However, today when I look at some of those datasets, they look like the space was first released (primary extent is 1 cyl, allocated was 200), and then as the data was loaded it took 11 secondary extents. This is exactly what I wanted to prevent. Can someone explain to me how this happened? General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 221 Storage class . . . : MEDIUM Allocated extents . : 12 Volume serial . . . : SSP122 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 204 Record format . . . : FB Used extents . . . : 12 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 1 Secondary cylinders : 20 Data set name type :SMS Compressible : NO The fact that the allocated cylinders is greater than the used cylinders (221 204) leads me to believe that space was not released from the dataset (allocated cylinders would equal used cylinders). The 1st extent is just the size of the first extent and not the primary space allocation amount. Each allocation can be up to five extents, even more if you are using the storage space constraint relief features of SMS. I recommend you look at the fragmentation index on your volume(s) and run some defrags. I think it's unlikely that the volume is so fragmented that the first extent allocated was only 1 cylinder, but that he was able to obtain a total of 220 cylinders in 12 extents. It is especially unlikely considering that the secondary allocation is 20 cylinders. My understanding is that allocation is using first fit strategy and the first extent could be only one cylinder if the next four extents equal or exceed 249 cylinders. The primary allocation amount for nonvsam datasets is not retained after the creating job completes. It is more likely that something caused the primary allocation to be 1 cylinder with 11 secondary allocations of 20 cylinders each. Storage space constraint relief could cause this which is why I suggested looking at fragmentation. I probably should have included amount of free space on the volume or in the SMS pool. There is not enough information to guess how this might have happened. I agree. If the OP has access to Dataset Audit Facility (DAF) from cbttape.org, the tale could be told. Regards, 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: APAR acronym
The intent of my OP was to supply historical information, not to stir up bootless controversy. APARs were indeed called 'Applied . . . ' before they were called 'Authorized . . .'. The adjective 'applied' once indeed figured prominently in IBM's marketing-organization names: The men and women we now call 'systems engineers' were once, for example, called 'applied science representatives' instead; etc., etc. Let me also note that I stopped posting regularly in this forum chiefly because I found myself feeling and, worse, exhibiting less and less patience with the effluvia of gratuitous, because radically uninformed, responses that my posts too often elicited. I now regret breaching my silence on this occasion; and I shall in the future try to exhibit even greater restraint, limiting myself to an occasional éloge. John Gilmore Ashland, MA 01721-1817 USA _ Make Windows Vista more reliable and secure with Windows Vista Service Pack 1. http://www.windowsvista.com/SP1?WT.mc_id=hotmailvistasp1banner -- 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: Shop zSeries Ordering Issues
-Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, May 05, 2008 4:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Shop zSeries Ordering Issues On Mon, 5 May 2008 11:27:41 -0700, Schwarz, Barry A wrote: I don't object to z/OS including Unix. I do object to being forced to use it for completely unrelated functions. One uses the most convenient tools available. c all /Unix/VSAM/ ... in your tirade and reset your clock a couple decades. History repeats itself. -- gil I still despise VSAM at times. Like right now due to not being able to share an open VSAM file across z/OS images. Granted, this is a documented restriction. But our programmers don't really care, they just want VSAM to work the way that __they__ want it to work, not the way it was designed. 1. VSAM RLS (free, but specialized programming needed). 2. DFSMStvs (Transactional VSAM; extra-cost product). -jc- -- 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: Shop zSeries Ordering Issues
TSO line edit? XEDIT? snip Just out of curiosity, which editor supports that syntax. I know ISPF would use c all Unix VSAM and I have a vague recollection of vi or some Unix editor using s/Unix/VSAM but I've never seen the two mixed before. . . . One uses the most convenient tools available. c all /Unix/VSAM/ /snip -- 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Tuesday, May 06, 2008 8:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY 3LR31/6.1. 8.9.1 And http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY 3PG32/1.13 .4.5 (In that order.) -jc- Yea, I gave them those references. They're gonna scream: I didn't need to do that in the PAST!!! sobwhinemoan -- 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: Shop zSeries Ordering Issues
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Tuesday, May 06, 2008 8:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Shop zSeries Ordering Issues I still despise VSAM at times. Like right now due to not being able to share an open VSAM file across z/OS images. Granted, this is a documented restriction. But our programmers don't really care, they just want VSAM to work the way that __they__ want it to work, not the way it was designed. 1. VSAM RLS (free, but specialized programming needed). 2. DFSMStvs (Transactional VSAM; extra-cost product). -jc- No CF. Management screamed at the cost of an ICF engine. And besides the mainframe is going away!. So nobody really seems to care about doing good fixes. Just ad hoc, minimal get it running type fixes. -- 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: SMS-releasing unused space
On Tue, 6 May 2008 08:25:42 -0400, John Kington wrote: Natasa, Hello, in order to prevent releasing of unused space for some datasets, I allocated it yesterday with MC that has Partial release parameter set to 'No'. However, today when I look at some of those datasets, they look like the space was first released (primary extent is 1 cyl, allocated was 200), and then as the data was loaded it took 11 secondary extents. This is exactly what I wanted to prevent. Can someone explain to me how this happened? General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 221 Storage class . . . : MEDIUM Allocated extents . : 12 Volume serial . . . : SSP122 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 204 Record format . . . : FB Used extents . . . : 12 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 1 Secondary cylinders : 20 Data set name type :SMS Compressible : NO The fact that the allocated cylinders is greater than the used cylinders (221 204) leads me to believe that space was not released from the dataset (allocated cylinders would equal used cylinders). The 1st extent is just the size of the first extent and not the primary space allocation amount. Each allocation can be up to five extents, even more if you are using the storage space constraint relief features of SMS. I recommend you look at the fragmentation index on your volume(s) and run some defrags. It seems implausible that if the volume is so fragmented that only one cylinder was available for the first extent, 20 cylinders were available for each of 11 following extents. Other possibilities: o The data set was migrated and recalled between allocation and use. o You didn't say what program populated the data set. I have an open PMR on very similar misbehavior by /bin/cp which has resulted in New Function APAR PK64372. (Development saw no way to repair the problem without changing a default behavior.) -- 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: Shop zSeries Ordering Issues
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, May 05, 2008 4:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Shop zSeries Ordering Issues On Mon, 5 May 2008 11:27:41 -0700, Schwarz, Barry A wrote: I don't object to z/OS including Unix. I do object to being forced to use it for completely unrelated functions. One uses the most convenient tools available. c all /Unix/VSAM/ ... in your tirade and reset your clock a couple decades. History repeats itself. -- gil I still despise VSAM at times. Like right now due to not being able to share an open VSAM file across z/OS images. Granted, this is a documented restriction. But our programmers don't really care, they just want VSAM to work the way that __they__ want it to work, not the way it was designed. -- 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: SMS-releasing unused space
Here is additional information: The dataset was allocated through ISPF panels (so there was no RLSE parameter), in subsequent daily batch it is used with DISP=OLD, program is ICEMAN. Management class MCNORLSE does not allow any migration, because those datasets are used every day. Regarding fragmentation, there are some very fragmented volumes in this storage group, but there were certainly volumes available that had 200 cyl extent free. Regards, Natasa -- 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: SMS-releasing unused space
It sounds up front as if the allocation was not estimated well enough in advance. Why not the 20 cylinders primary and 20 cylinders secondary with a RLSE? Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/06/2008 09:29:33 AM: -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: Natasa Savinc [EMAIL PROTECTED] Subject: Re: SMS-releasing unused space --- Here is additional information: The dataset was allocated through ISPF panels (so there was no RLSE parameter), in subsequent daily batch it is used with DISP=OLD, program is ICEMAN. Management class MCNORLSE does not allow any migration, because those datasets are used every day. Regarding fragmentation, there are some very fragmented volumes in this storage group, but there were certainly volumes available that had 200 cyl extent free. Regards, Natasa -- 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 Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Tuesday, May 06, 2008 8:25 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) Yea, I gave them those references. They're gonna scream: I didn't need to do that in the PAST!!! sobwhinemoan Yes, you did. You just got lucky, and got away with not doing it. sound effect Washing hands. /sound effect -jc- I am now totally elided at the programmer. Who obvious is a elided. The code in their program, on OPEN, tests for an RC of 00 or 92 (should be 97). And then just unconditionally sets the VSAM return code to 90 and complains. I'm not too happy with myself either. I actually __believed__ him without double checking all the source myself. Not gonna do that again. -- 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: SMS-releasing unused space
Natasa, Here is additional information: The dataset was allocated through ISPF panels (so there was no RLSE parameter), in subsequent daily batch it is used with DISP=OLD, program is ICEMAN. Management class MCNORLSE does not allow any migration, because those datasets are used every day. Regarding fragmentation, there are some very fragmented volumes in this storage group, but there were certainly volumes available that had 200 cyl extent free. I would highly recommend getting Dataset Audit Facility (DAF) from cbttape.org and run the SMF records through it to build a history of the dataset. This history might tell you what happened and when. Since you appear to be allocating these datasets manually, can you check the space information just after you create them? Regards, 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: SMS-releasing unused space
Daniel, because the size of the dataset is one day 200 cyl, another day 300 cyl or more, and during the weekend 10 cly. When we had RLSE, number of extents was steadily growing. Regards, Natasa -- 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: SMS-releasing unused space
On Tue, 6 May 2008 09:05:34 -0400, John Kington wrote: Tom Marchant wrote: I think it's unlikely that the volume is so fragmented that the first extent allocated was only 1 cylinder, but that he was able to obtain a total of 220 cylinders in 12 extents. It is especially unlikely considering that the secondary allocation is 20 cylinders. My understanding is that allocation is using first fit strategy and the first extent could be only one cylinder if the next four extents equal or exceed 249 cylinders. First fit may very well be the strategy that is used, but DADSM tries to provide the primary allocation in one extent. I always thought that when the primary allocation had to be done in multiple extents that the first extent is the largest. Perhaps someone will correct me if I'm mistaken. The primary allocation amount for nonvsam datasets is not retained after the creating job completes. That is true. -- Tom Marchant -- 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: SMS-releasing unused space
If that is known then 1 cylinder primary is automatically too small. Why nott 20/200? Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/06/2008 09:46:53 AM: -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: Natasa Savinc [EMAIL PROTECTED] Subject: Re: SMS-releasing unused space --- Daniel, because the size of the dataset is one day 200 cyl, another day 300 cyl or more, and during the weekend 10 cly. When we had RLSE, number of extents was steadily growing. Regards, Natasa -- 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 Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: APAR acronym
Many years ago at Guide Montral (83?) I heard the key note speaker say APAR stood for Atempt to Prevent A Reoccurance PTF stood for Possibly The Fix Avram Friedman On Mon, 5 May 2008 13:54:18 +, john gilmore [EMAIL PROTECTED] wrote: The standard interpretation of APAR is now Authorized . . . ; but it was once Applied . . . instead, which then made sense in relation to the organizational terminology in use within IBM but makes none now. IBM's practice of jacking up acronyms to replace their current, notionally obsolescent, expansions with new, notionally more felicitous, ones is a longstanding one; and large conclusions drawn from a current expansion can thus be problematic. John Gilmore Ashland, MA 01721-1817USA _ With Windows Live for mobile, your contacts travel with you. http://www.windowslive.com/mobile/overview.html? ocid=TXT_TAGLM_WL_Refresh_mobile_052008 -- 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: SMS-releasing unused space
John, I will see about DAF, thank you for the information. The idea was to allocate the dataset manually, in order to assign it new MC, and to avoid changing daily batch and ACS routines. I allocated it again, and this time I checked actual allocation: General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 200 Storage class . . . : MEDIUM Allocated extents . : 1 Volume serial . . . : SSP100 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 0 Record format . . . : FB Used extents . . . : 0 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 200 Secondary cylinders : 20 Data set name type :SMS Compressible : NO We'll see what happens tomorrow. Regards, Natasa -- 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: SMS-releasing unused space
Daniel, allocation was 200/20. My question was something like where did this 1 come from? Regards, Natasa -- 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
Question on RACF database upgrade for z/OS 1.7-1.8
Hi Just starting to plan the 1.7- 1.8 z/OS upgrade We have a four-system sysplex and intent to go to 1.8 by doing a rolling update over a week. Ie there will be about a week with some systems running z/OS 1.8 and some running z/OS 1.7 One thing I can't seem to find unambiguous information about is the update path for the RACF database, ((which is shared by all systems in the plex)) At the moment we plan to do the following: a) ON a 1.7 SYSTEM run IRRMIN00 UPDATE at level 1.8 (ie with the service pack library STEPLIBed) against the 1.7 primary database. b) ON a 1.7 SYSTEM run IRRMIN00 UPDATE at level 1.8 (ie with the service pack library STEPLIBed) against the 1.7 secondary database. c) Run for a few days d) IPL some systems from the 1.8 residence pack e) Run for a few more days doing other testing f) Ipl all systems from the 1.8 residence pack Is this safe? Will the 1.7 systems tolerate the 1.8 templates in the database? Or should we go the other way and do the upgrade after we IPL to 1.8? Hope this is clear. -- 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: Question on RACF database upgrade for z/OS 1.7-1.8
On Tue, 6 May 2008 09:07:07 -0500, Andy Robertson [EMAIL PROTECTED] wrote: Hi Just starting to plan the 1.7- 1.8 z/OS upgrade We have a four-system sysplex and intent to go to 1.8 by doing a rolling update over a week. Ie there will be about a week with some systems running z/OS 1.8 and some running z/OS 1.7 One thing I can't seem to find unambiguous information about is the update path for the RACF database, ((which is shared by all systems in the plex)) At the moment we plan to do the following: a) ON a 1.7 SYSTEM run IRRMIN00 UPDATE at level 1.8 (ie with the service pack library STEPLIBed) against the 1.7 primary database. b) ON a 1.7 SYSTEM run IRRMIN00 UPDATE at level 1.8 (ie with the service pack library STEPLIBed) against the 1.7 secondary database. c) Run for a few days d) IPL some systems from the 1.8 residence pack e) Run for a few more days doing other testing f) Ipl all systems from the 1.8 residence pack Is this safe? Will the 1.7 systems tolerate the 1.8 templates in the database? Or should we go the other way and do the upgrade after we IPL to 1.8? That will be fine. As an alternative, you can now IPL from 1.8 and if the correct templates aren't there, temporary ones will be used. After you have done some initial testing you can run IRRMIN00 UPDATE from a 1.8 system without the STEPLIB. I think this has been true since 1.6. 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 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: VSAM / COBOL question - redux (fwd)
John, snip Yea, I gave them those references. They're gonna scream: I didn't need to do that in the PAST!!! sobwhinemoan /snip Were you running on multiple physical machines in the past? Or a single machine, single LPAR in the past? If so, then you need to remind them that file locking, in support of multiple program access, is different between 2 or more logical or physical machines. Going from a single machine, single image (LPAR) to a single machine multiple LPARs is basically the equivalent of 2 or more physical machines each capable of access data. This data access has to be controlled and as such provides the benefits of communicating file status information amongst the users (programs) accessing the files. So, yes, they didn't have to do it in the past, because they were on a single image on a single machine. Yes, now they need to do it because you effectively have multiple machines accessing the same files from different directions. Hope this helps in the battle. Chuck -- 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: APAR acronym
On Tue, 6 May 2008 13:10:57 +, john gilmore wrote: The intent of my OP was to supply historical information, not to stir up bootless controversy. APARs were indeed called 'Applied . . . ' before they were called 'Authorized . . .'. The adjective 'applied' once indeed figured prominently in IBM's marketing-organization names: The men and women we now call 'systems engineers' were once, for example, called 'applied science representatives' instead; etc., etc. Let me also note that I stopped posting regularly in this forum chiefly because I found myself feeling and, worse, exhibiting less and less patience with the effluvia of gratuitous, because radically uninformed, responses that my posts too often elicited. I now regret breaching my silence on this occasion; and I shall in the future try to exhibit even greater restraint, limiting myself to an occasional éloge. Some of that has to do with the arrogance with which you post. Radically uninformed? Perhaps so. I've only been working with APARs since the early '70s and they were Authorized... then. I'm sorry, but I no longer have any references. Apparently neither do you. Gartuitous? PKB -- Tom Marchant -- 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: Question on RACF database upgrade for z/OS 1.7-1.8
- Original Message - From: Andy Robertson [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Tuesday, May 06, 2008 10:07 AM Subject: Question on RACF database upgrade for z/OS 1.7-1.8 Hi Just starting to plan the 1.7- 1.8 z/OS upgrade We have a four-system sysplex and intent to go to 1.8 by doing a rolling update over a week. Ie there will be about a week with some systems running z/OS 1.8 and some running z/OS 1.7 One thing I can't seem to find unambiguous information about is the update path for the RACF database, ((which is shared by all systems in the plex)) At the moment we plan to do the following: a) ON a 1.7 SYSTEM run IRRMIN00 UPDATE at level 1.8 (ie with the service pack library STEPLIBed) against the 1.7 primary database. b) ON a 1.7 SYSTEM run IRRMIN00 UPDATE at level 1.8 (ie with the service pack library STEPLIBed) against the 1.7 secondary database. c) Run for a few days d) IPL some systems from the 1.8 residence pack e) Run for a few more days doing other testing f) Ipl all systems from the 1.8 residence pack Is this safe? Will the 1.7 systems tolerate the 1.8 templates in the database? Or should we go the other way and do the upgrade after we IPL to 1.8? Andy, You'll have to check with IBM on the specifics of whether a 1.8 templates will be accepted on a 1.7 system. We had a 1.5 database that IBM swore up and down would run on 1.4, until we had to run IRRUT400 while we were still at 1.4. IRRUT400 gagged, choked, and coughed trying to update the 1.5 database at the 1.4 level. Everything else worked, but it put a severe crimp in our upgrade path. Regards, Tom Conley -- 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: SMS-releasing unused space
On Tue, 6 May 2008 08:46:53 -0500, Natasa Savinc wrote: because the size of the dataset is one day 200 cyl, another day 300 cyl or more, and during the weekend 10 cly. When we had RLSE, number of extents was steadily growing. You reuse this data set? How do you empty it to prepare for the next run? Perhaps that is what is releasing the space. -- Tom Marchant -- 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: Heads Up: WSC Flash - Bad PTFs
Jousma, David wrote: Sneer might be a bit strong. Rather than 10 posts about how it couldn't be cut/paste, I just typed it up once for everyone, knowing that webpage don't get updated very quick Lots of people talk about how somebody ought to do something. Some people talk about doing something. A few people actually do something. Thanks, Dave! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.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: SMS-releasing unused space
Natasa, Can you show us the MCNORLSE attributes? Also, do you have STOPX37, SRS or similar products? These products have the ability to manipulate allocations. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Natasa Savinc Sent: Tuesday, May 06, 2008 9:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SMS-releasing unused space John, I will see about DAF, thank you for the information. The idea was to allocate the dataset manually, in order to assign it new MC, and to avoid changing daily batch and ACS routines. I allocated it again, and this time I checked actual allocation: General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 200 Storage class . . . : MEDIUM Allocated extents . : 1 Volume serial . . . : SSP100 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 0 Record format . . . : FB Used extents . . . : 0 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 200 Secondary cylinders : 20 Data set name type :SMS Compressible : NO We'll see what happens tomorrow. Regards, Natasa -- 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: Java Batch
David - Yes, it does help to reduce JVM start-up times, which are mostly about class-loading and JITing. YMMV On Mon, May 5, 2008 at 2:52 PM, David Andrews [EMAIL PROTECTED] wrote: On Mon, 2008-05-05 at 14:32 -0500, Kirk Wolf wrote: SDK 6 has a feature (AOT) whereby these optimizations can be reused over and over between different jobs. Kirk, does this do much to reduce the startup cost for Java-in-batch? -- 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 -- 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: Service Unit to CPU minute conversion
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/06/2008 09:04:33 AM: I have a request from management to give them the number of CPU minutes used for a certain time period per application. I have the numbers for numbers of service units for each period and application, but I need to know what conversion factor I can use to convert this to CPU minutes? Is there a manual that walks me through this process? Also, we are on a 2064-102. which I would think would be a factor in the conversion process. I seem to remember that service units apply based on a machine type? It's in an appendix of the MVS Planning: Workload Management book for the appropriate release. It is dependent on machine type and number of CPs. --- Kevin McKenzie External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 -- 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: Service Unit to CPU minute conversion
On Tue, 6 May 2008 08:04:33 -0500, Todd Burrell wrote: I have a request from management to give them the number of CPU minutes used for a certain time period per application. I have the numbers for numbers of service units for each period and application, but I need to know what conversion factor I can use to convert this to CPU minutes? Is there a manual that walks me through this process? Also, we are on a 2064-102. You will not get accurate data that way because service units are not accumulated only for CPU usage. You'd do better to get CPU times from SMF data. That said, however, the Planning: Workload Management manual has a chart showing the number of service units per second for each processor in Appendix B. It is also in the Init and Tuning Guide, section 3.5.2, Preparing an Initial OPT. For your z900 model 102, the number is 10891.8 service units per second of CPU time. This is the factor that is used to calculate unweighted CPU service units per second from CPU time. You'll need to adjust for the CPU service coefficient. -- Tom Marchant -- 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: Shop zSeries Ordering Issues
snip- I still despise VSAM at times. Like right now due to not being able to share an open VSAM file across z/OS images. Granted, this is a documented restriction. But our programmers don't really care, they just want VSAM to work the way that __they__ want it to work, not the way it was designed. -unsnip Do they *want* their SUV's to fly as well? We all have to live with some limitations, however unreasonable we might feel those limitations. I can think of a few people that seriously need killing, but I can't do it. We learn to adapt; so can those programmers. Slap them up-side the head and teach them about VSAM buffers in storage, index updating, etc. Then maybe, just maybe, they'll understand why they can't always get what they want. :-) (Also, remind them how bad ISAM was; that ought to get their attention.) -- 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: Service Unit to CPU minute conversion
---snip-- I have a request from management to give them the number of CPU minutes used for a certain time period per application. I have the numbers for numbers of service units for each period and application, but I need to know what conversion factor I can use to convert this to CPU minutes? Is there a manual that walks me through this process? Also, we are on a 2064-102. which I would think would be a factor in the conversion process. I seem to remember that service units apply based on a machine type? I looked through the archives and did not see anything that specifically addressed this, so I figured I'd ask the group. -unsnip--- At one time, there was a table in the Init Tuning Guide that told you how many Service Units per Second for the various CPU's. I don't know if it's still there or not. If not, you might open a ETR with IBM. (If so, please share the results with the list. :-) ) -- 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: SMS-releasing unused space
snip- Storage space constraint relief could cause this which is why I suggested looking at fragmentation. I probably should have included amount of free space on the volume or in the SMS pool. -unsnip--- I submit that if there was enough free space to accumulate 11 secondary extents of 20 cylinders each that fragmentation or constraint relief are not issues here. I, too, want to see the actual DD statement that made the allocation. -- 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: Service Unit to CPU minute conversion
I tracked down the Service unit to CPU second conversion constants in the Init and Tuning Guide. This is what I need, because I have the SU's already from the type 30 SMF records. Once I put in the coefficients, I should have a good number. Thanks to everyone that replied. It had just been awhile since I messed with this, and I forgot where the numbers and constants were. C. Todd Burrell Lead z/OS Systems Programmer ITSO (404) 723-2017 (Cell) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Mckenzie Sent: Tuesday, May 06, 2008 10:50 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Service Unit to CPU minute conversion IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/06/2008 09:04:33 AM: I have a request from management to give them the number of CPU minutes used for a certain time period per application. I have the numbers for numbers of service units for each period and application, but I need to know what conversion factor I can use to convert this to CPU minutes? Is there a manual that walks me through this process? Also, we are on a 2064-102. which I would think would be a factor in the conversion process. I seem to remember that service units apply based on a machine type? It's in an appendix of the MVS Planning: Workload Management book for the appropriate release. It is dependent on machine type and number of CPs. --- Kevin McKenzie External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 -- 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: APAR acronym
--snip Let me also note that I stopped posting regularly in this forum chiefly because I found myself feeling and, worse, exhibiting less and less patience with the effluvia of gratuitous, because radically uninformed, responses that my posts too often elicited. I now regret breaching my silence on this occasion; and I shall in the future try to exhibit even greater restraint, limiting myself to an occasional éloge. unsnip Don't be a stranger, John. Please remember that Sysprogs are a lot like kids. You spend the first two years teaching them to walk and talk, and the next 18 years telling them to sit down and shut up. Then they (FINALLY) reach maturity. The calendar may be different, (and it varies with individual cases) but the process is the same. :-) -- 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: VSAM / COBOL question - redux (fwd)
---snip--- I am now totally elided at the programmer. Who obvious is a elided. The code in their program, on OPEN, tests for an RC of 00 or 92 (should be 97). And then just unconditionally sets the VSAM return code to 90 and complains. I'm not too happy with myself either. I actually __believed__ him without double checking all the source myself. Not gonna do that again. ---unsnip--- elided # 1 = Inapropriate term for thoroughly disgusted, disgruntled and angry with?? elided # 2 = Similarly inappropriate term, possibly an anatomical reference, for a total jerk?? Want to borrow my cast-iron baseball bat ?? :-) -- 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: Question on RACF database upgrade for z/OS 1.7-1.8
On Tue, 6 May 2008 10:22:21 -0400, Pinnacle [EMAIL PROTECTED] wrote: You'll have to check with IBM on the specifics of whether a 1.8 templates will be accepted on a 1.7 system. We had a 1.5 database that IBM swore up and down would run on 1.4, until we had to run IRRUT400 while we were still at 1.4. IRRUT400 gagged, choked, and coughed trying to update the 1.5 database at the 1.4 level. Everything else worked, but it put a severe crimp in our upgrade path. That is the nice thing about the new support. You don't have to actually run the update until you have an LPAR that you know won't be backed out to the lower level. But I'm still surprised about your problem, because we've always updated the templates as we were getting ready to IPL our first sharing LPAR in the past. And I'm pretty sure we did the 1.6 templates when IPLing on a weekend for an initial test and then backed off to z/OS 1.4 without any problems. As far as your particular problem... did you try and STEPLIB to the 1.5 level of IRRUT400? 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 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Tuesday, May 06, 2008 10:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) ---snip--- I am now totally elided at the programmer. Who obvious is a elided. The code in their program, on OPEN, tests for an RC of 00 or 92 (should be 97). And then just unconditionally sets the VSAM return code to 90 and complains. I'm not too happy with myself either. I actually __believed__ him without double checking all the source myself. Not gonna do that again. ---unsnip--- elided # 1 = Inapropriate term for thoroughly disgusted, disgruntled and angry with?? Yes, don't want to be NOPOST'ed by Darren. elided # 2 = Similarly inappropriate term, possibly an anatomical reference, for a total jerk?? Actually a reference to the size (or lack thereof) of his cranium. Perhaps also a resident of the isle of Crete? Want to borrow my cast-iron baseball bat ?? :-) For him? Or me? grin -- 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: Question on RACF database upgrade for z/OS 1.7-1.8
snip- That will be fine. As an alternative, you can now IPL from 1.8 and if the correct templates aren't there, temporary ones will be used. After you have done some initial testing you can run IRRMIN00 UPDATE from a 1.8 system without the STEPLIB. I think this has been true since 1.6. ---unsnip- I've always run the update from the driving system, using the new templates as soon as they were available, even if the newer system wasn't running yet. Long ago I questioned the RACF support staff about this. I was assured that a down-level RACF simply ignored any templates that it didn't understand. -- 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: Question on RACF database upgrade for z/OS 1.7-1.8
- Original Message - From: Mark Zelden [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Tuesday, May 06, 2008 11:37 AM Subject: Re: Question on RACF database upgrade for z/OS 1.7-1.8 On Tue, 6 May 2008 10:22:21 -0400, Pinnacle [EMAIL PROTECTED] wrote: You'll have to check with IBM on the specifics of whether a 1.8 templates will be accepted on a 1.7 system. We had a 1.5 database that IBM swore up and down would run on 1.4, until we had to run IRRUT400 while we were still at 1.4. IRRUT400 gagged, choked, and coughed trying to update the 1.5 database at the 1.4 level. Everything else worked, but it put a severe crimp in our upgrade path. That is the nice thing about the new support. You don't have to actually run the update until you have an LPAR that you know won't be backed out to the lower level. But I'm still surprised about your problem, because we've always updated the templates as we were getting ready to IPL our first sharing LPAR in the past. And I'm pretty sure we did the 1.6 templates when IPLing on a weekend for an initial test and then backed off to z/OS 1.4 without any problems. As far as your particular problem... did you try and STEPLIB to the 1.5 level of IRRUT400? Mark, This was about 3 years ago, so the details are fuzzy. The client ordered an immediate backout to the 1.4 database. Can't remember what we tried at the time. Tom -- 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
Module IAXVP CPU activity - real storage management
I've got a module IAXVP eating 25% of the CPU of some of my busiest CICS regions - CICS 3.1, zOS 1.8 Its to do with real storage management. And these aren't the biggest real storage eaters in CICS . I don't have any real storage problems, and ive got 32 gb on the machine Anyone got any suggestions as to what might cause this or what to look at? -- Disclaimer:This email is for the use of the addressee only and may contain information that is confidential, privileged and/or subject to copyright. Any views expressed in this email communication are those of the individual sender, except where the sender specifically states them to be the views of CPT Global. CPT Global does not represent, warrant or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus or interference. If you are not the intended recipient, you must not read, print, store, copy, forward or use this email for any reason, in accordance with privacy and copyright laws. If you have received this email in error, please notify the sender immediately and delete the email. Thank you. Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg -- 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: Module IAXVP CPU activity - real storage management
Ken Williams wrote: I've got a module IAXVP eating 25% of the CPU of some of my busiest CICS regions - CICS 3.1, zOS 1.8 Its to do with real storage management. And these aren't the biggest real storage eaters in CICS . I don't have any real storage problems, and ive got 32 gb on the machine Anyone got any suggestions as to what might cause this or what to look at? Does this fit? APAR Identifier .. OA24094 https://www-304.ibm.com/jct03004c/ibmlink/sis/viewAparDoc.wss?context=aparAndUsagedocumentIds=OA24094lc=encc=US Last Changed 08/05/05 IN A CICS TRANSACTION ISOLATION ENVIRONMENT (IE. USING SUBSPACES) HIGH PERFORMANCE OVERHEAD IN IAXVP DOING CSP Symptom .. PR PERFM Status ... OPEN Severity ... 2 Date Closed . Component .. 5752SC1CR Duplicate of Reported Release . 730 Fixed Release Component Name 5752 REAL STOR Special Notice Current Target Date ..08/05/23 Flags SCP ... Platform Status Detail: REVIEW - APAR solution is being reviewed. PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: In a CICS transaction isolation enviroment (ie. subspaces are being utilized), very high performance overhead occurs in IAXVP during CSP processing due to the private storage getmains being done which drives page table initialization. The cause of the high performance impact is the PTLB (purge translation lookaside buffers) which occurs upon the CSP instruction. LOCAL FIX: Note: This problem will not be encountered if NOT running in a CICS transaction isolation environment where subspaces are NOT utilized. -- Mark Jacobs Time Customer Service Tampa, FL Progress doesn't come from early risers - progress is made by lazy men looking for easier ways to do things. Robert A. Heinlein - Time Enought for Love(1973) -- 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: Module IAXVP CPU activity - real storage management
On Wed, 7 May 2008 02:23:51 +1000, Ken Williams wrote: I've got a module IAXVP eating 25% of the CPU of some of my busiest CICS regions - CICS 3.1, zOS 1.8 Its to do with real storage management. And these aren't the biggest real storage eaters in CICS . I don't have any real storage problems, and ive got 32 gb on the machine Anyone got any suggestions as to what might cause this or what to look at? -- APAR OA24094? Brian -- 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: VSAM / COBOL question - redux (fwd)
They're gonna scream: I didn't need to do that in the PAST!!! sobwhinemoan That is their problem! Progress requires change. If your management mandated Parallel SYSPLEX (which I believe is progress), then people have to change! There is no point in moaning about the past; face the future, together. - 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, May 06, 2008 11:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) They're gonna scream: I didn't need to do that in the PAST!!! sobwhinemoan That is their problem! Progress requires change. If your management mandated Parallel SYSPLEX (which I believe is progress), then people have to change! There is no point in moaning about the past; face the future, together. - Too busy driving to stop for gas! Not parallel sysplex, it costs too much (ICF engine). We are a basic sysplex. And not for any good reason, IMO. -- 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: Shop zSeries Ordering Issues
Does the Internet receive still require cryptographic services? Jon -- 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: VSAM / COBOL question - redux (fwd)
This thread is morphing into the user key CSA thread. Just because bad practices once appeared to be successful, they were still bad! Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, May 06, 2008 8:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Tuesday, May 06, 2008 8:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY 3LR31/6.1. 8.9.1 And http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY 3PG32/1.13 .4.5 (In that order.) -jc- Yea, I gave them those references. They're gonna scream: I didn't need to do that in the PAST!!! sobwhinemoan -- 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 -- 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: VSAM / COBOL question - redux (fwd)
Yea, I gave them those references. They're gonna scream: I didn't need to do that in the PAST!!! sobwhinemoan Yes, you did. You just got lucky, and got away with not doing it. sound effect Washing hands. /sound effect The phrase I like to use is: Working By Coincidence. -- 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: Shop zSeries Ordering Issues
No it doesn't, but check back thru the archives for the past 6 months. I had an issue where I don't have crypto, either in hardware or in the appropriate level of JAVA, and hit some snags due to incorrect DDDEF entries in my receive job. You can contact me offlist if you want me to dig back thru my notes on it. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Tuesday, May 06, 2008 12:15 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Shop zSeries Ordering Issues Does the Internet receive still require cryptographic services? Jon -- 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: VSAM / COBOL question - redux (fwd)
I am now totally elided at the programmer. Who obvious is a elided. The code in their program, on OPEN, tests for an RC of 00 or 92 (should be 97). And then just unconditionally sets the VSAM return code to 90 and complains. I'm not too happy with myself either. I actually __believed__ him without double checking all the source myself. Not gonna do that again. There may not be any deliberate deception involved. Programmers will tell you what they coded, but what they *really* mean is: This is what I *think* I coded or This is what I *meant* to code. RTFC is the only way to be sure. -- 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don Leahy Sent: Tuesday, May 06, 2008 12:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) I am now totally elided at the programmer. Who obvious is a elided. The code in their program, on OPEN, tests for an RC of 00 or 92 (should be 97). And then just unconditionally sets the VSAM return code to 90 and complains. I'm not too happy with myself either. I actually __believed__ him without double checking all the source myself. Not gonna do that again. There may not be any deliberate deception involved. Programmers will tell you what they coded, but what they *really* mean is: This is what I *think* I coded or This is what I *meant* to code. RTFC is the only way to be sure. True, but I think the __programmer__ should do that, at lease initially. I generally don't have time to go into Endevor and find the compile listing of the program mentioned by the programmer. Understand it, then realize that the actual code is in another program which is called by the main program and look at it and try to understand it as well. That is not really my job. I'm not, generally, an expert COBOL programmer by any means. -- 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: Shop zSeries Ordering Issues
My tapes didn't require crytographic or JAVA interference. G Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/06/2008 01:35:40 PM: -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: Pommier, Rex R. [EMAIL PROTECTED] Subject: Re: Shop zSeries Ordering Issues --- No it doesn't, but check back thru the archives for the past 6 months. I had an issue where I don't have crypto, either in hardware or in the appropriate level of JAVA, and hit some snags due to incorrect DDDEF entries in my receive job. You can contact me offlist if you want me to dig back thru my notes on it. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Tuesday, May 06, 2008 12:15 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Shop zSeries Ordering Issues Does the Internet receive still require cryptographic services? Jon -- 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 Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: allowuserkeycsa
As I understand it, IDMS specifically has a problem with NO. Patrick Loftus wrote: We've been using the default of YES up to z/OS 1.8, but will now take the default of NO for z/OS 1.9. Shouldn't be any problem, as we will discover any issues when rolling out through various systems. So far we've discovered a bug in our Sysprog sysplex with a BMC DB2 utility, but they've released a fix for that now. You can dynamically switch from NO to YES anyway, should it cause issues. -- 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: Question on RACF database upgrade for z/OS 1.7-1.8
My MVS guy IPL'ed 1 of our dev systems under z/OS 1.8 --- I ran the template job, he then re-ipled that system and then brought the other Development systems up under 1.8. We ran Dev 1.8 and Prod 1.7 for about a month with no problems. Keep in mind that the Migration Guide indicates to do it this way. IE: Security Server actions to perform after the first IPL of z/OS V1R8. This section describes Security Server migration actions that you can perform only after you have IPLed z/OS V1R8. You need a running z/OS V1R8 system to perform these actions. Update database templates Description: To ensure that the RACF utilities function properly, use the IRRMIN00 utility to update the test and production RACF databases with the database templates for the current release level. Also, there is a z/OS 1.7 - 1.8 compatibility issue ... Migration Guide also indicates: Security Server: In z/OS V1R8, the structure of the RACF database was changed to allow a template block to be continued into another block. The PTF allows a z/OS V1R7 system to process templates that extend into another block. If you share a RACF database between z/OS V1R8 and z/OS V1R7, you need to install the PTF on the z/OS V1R7 system. UA24980 Rgrds, Joseph Sumi Lockheed Martin Information Technology z/OS RACF Systems Programming -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Andy Robertson Sent: Tuesday, May 06, 2008 10:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Question on RACF database upgrade for z/OS 1.7-1.8 Hi Just starting to plan the 1.7- 1.8 z/OS upgrade We have a four-system sysplex and intent to go to 1.8 by doing a rolling update over a week. Ie there will be about a week with some systems running z/OS 1.8 and some running z/OS 1.7 One thing I can't seem to find unambiguous information about is the update path for the RACF database, ((which is shared by all systems in the plex)) At the moment we plan to do the following: a) ON a 1.7 SYSTEM run IRRMIN00 UPDATE at level 1.8 (ie with the service pack library STEPLIBed) against the 1.7 primary database. b) ON a 1.7 SYSTEM run IRRMIN00 UPDATE at level 1.8 (ie with the service pack library STEPLIBed) against the 1.7 secondary database. c) Run for a few days d) IPL some systems from the 1.8 residence pack e) Run for a few more days doing other testing f) Ipl all systems from the 1.8 residence pack Is this safe? Will the 1.7 systems tolerate the 1.8 templates in the database? Or should we go the other way and do the upgrade after we IPL to 1.8? Hope this is clear. -- 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: VSAM / COBOL question - redux (fwd)
On Tue, May 6, 2008 at 1:47 PM, McKown, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don Leahy Sent: Tuesday, May 06, 2008 12:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) I am now totally elided at the programmer. Who obvious is a elided. The code in their program, on OPEN, tests for an RC of 00 or 92 (should be 97). And then just unconditionally sets the VSAM return code to 90 and complains. I'm not too happy with myself either. I actually __believed__ him without double checking all the source myself. Not gonna do that again. There may not be any deliberate deception involved. Programmers will tell you what they coded, but what they *really* mean is: This is what I *think* I coded or This is what I *meant* to code. RTFC is the only way to be sure. True, but I think the __programmer__ should do that, at lease initially. I generally don't have time to go into Endevor and find the compile listing of the program mentioned by the programmer. Understand it, then realize that the actual code is in another program which is called by the main program and look at it and try to understand it as well. That is not really my job. I'm not, generally, an expert COBOL programmer by any means. I agree that it is the programmers job to RTFC. Many of them (us, actually, since I am a programmer) are too lazy, especially if the code in question was written by someone else. attempt humour I think that is why some systems programmers seek to induce fear in the hearts of application programmers. I used to think that this was merely a form of torture for the sysprog's amusement, but I believe this is actually a type of training. The sysprog's hope is that if he consistently ridicules them for asking stupid questions, eventually the questions will get better. Maybe even to the point that the programmer will start to RTFC (and RTFM!) before asking for help. A forlorn hope perhaps. /attempt humour -- 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don Leahy Sent: Tuesday, May 06, 2008 1:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) I agree that it is the programmers job to RTFC. Many of them (us, actually, since I am a programmer) are too lazy, especially if the code in question was written by someone else. attempt humour I think that is why some systems programmers seek to induce fear in the hearts of application programmers. I used to think that this was merely a form of torture for the sysprog's amusement, but I believe this is actually a type of training. The sysprog's hope is that if he consistently ridicules them for asking stupid questions, eventually the questions will get better. Maybe even to the point that the programmer will start to RTFC (and RTFM!) before asking for help. A forlorn hope perhaps. /attempt humour Nay, we do it for fun. We are all basically BOFH's really. -- 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: allowuserkeycsa
On Tue, 6 May 2008 12:53:57 -0500, Michael Babcock [EMAIL PROTECTED] wrote: As I understand it, IDMS specifically has a problem with NO. As does CA-DATACOM the last I checked. There is an option to change it for current version(s?) (which we do for CA-11's DATACOM) but when our DBA checked into this last year we were warned of a performance impact in using the alternative option in our production online environment. If anyone has a large-ish (FSVO large) production DATACOM environment and has made that change, I'd be interested in knowing what performance impact if any it had and if any end users really noticed it or if it was measurable in terms of CPU usage etc. 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 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: (Mainframe has competition was fwd) Re: COBOL Compiler for Windows
All, I read the response below in regard to below to Sabre. I have a comment and take for what it's worth ( 30+ yrs - IBM MVS/VM/VSE/VTAM/CICS/TCPIP/NCP ) and now a developer. The thing that drove everyone off Mainframes according to reports was the cost. So now small and medium shops have 1 or 2 or 3 mainframes to do the work and to convert to Unix or Windows they have 30 or more Unix or windows servers to accomplish usually less and more staff required...Unfortunately, it usually boils down to money. After working for a very very large IBM customer nationally and internationally for many years I saw the effect of a company with mucho bucks, we got just about anything we wanted, as long as we bought software and hardware from IBM. When they switched to Hitachi, well the attitude toward the company changed significantly. I wonder why ??? Scott Ford Senior Host Developer | Forging Enterprise Identity | IdentityForge.com (Main) 678.266.3399 x304 | (Cell) 609.346.0399 | (Fax) 678.266.3399 [EMAIL PROTECTED] This message is for the designated recipient only and may contain priviledged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and then delete the original. Any other use of the email by you is prohibited. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples Sent: Monday, May 05, 2008 3:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: (Mainframe has competition was fwd) Re: COBOL Compiler for Windows For example, Sabre (airline reservations, Travelocity) cut its total expenses 50% when it switched from mainframe to Unix. I do not have any particular knowledge of Sabre, so I would assume absent any information to the contrary that they're wonderful people. But I do have a problem with whoever this poster is. I would advise everyone to turn their marketing BS detectors to maximum when you see claims like these. Always sanity check them. It's really quite easy to do. Sabre Holdings went private in early 2007 (in a buyout by Silver Lake and Texas Pacific Group), but they did publish their full year 2006 financial results. Between 2005 and 2006 their operating expenses *increased* 12.3%, while total revenues increased a more modest 12.0%. The comparable figures are +20.7% and +18.3% for the year prior (2005 v. 2004). You can find these data on their Web site. When your costs increase faster than your revenues you suffer declining gross margins in your business. Perhaps somebody could check prior years to see if any of them show a 50% decrease in operating expenses. (I seriously doubt it.) It might also be interesting to see margin trends, especially relative to peer competitors. Here's another sanity check. The biggest corporate operating expense is generally payroll. Sabre reported having about 9,000 employees at the end of 2006. If you assume each employee has a fully burdened expense of $150,000 -- probably about right -- then that would be an annual total expense of $1.35 billion. That amount is more than half of Sabre's entire operating expenses for 2006, which makes sense given Sabre's business. In other words, for the poster's claim to be true Sabre would either have to fire almost every employee (without hiring replacement contractors) or slash every non-payroll cost to zero. (The latter wouldn't quite make the goal, actually.) So they'd either have buildings, equipment, and other assets with no employees to operate them, or they'd have 9,000 employees who don't have a single computer among them. Anybody think either case is realistic? :-) Look, if there are numerous and frequent strong business cases for moving off the mainframe, why does this particular individual (at least) have to fall back on ridiculous claims that are rather easily disproved by just checking corporate annual reports? Why not just present honest facts if the facts are so wonderful? Should a rational person believe any other claims from such a person? (Again, I don't know much about Sabre, so I don't even know if they switched from mainframe to Unix.) That said, I do agree with one thought: there's choice and competition in where to run workloads. As a reminder, my opinions are my own and do not necessarily represent those of my employer or anyone else. - - - - - 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED]
Re: Shop zSeries Ordering Issues
Thanks for the tip. I have avoided FROMNETWORK in the past since we haven't configured cryptographic services, but I may give it a shot next time. Thanks, Jon -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Tuesday, May 06, 2008 1:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Shop zSeries Ordering Issues No it doesn't, but check back thru the archives for the past 6 months. I had an issue where I don't have crypto, either in hardware or in the appropriate level of JAVA, and hit some snags due to incorrect DDDEF entries in my receive job. You can contact me offlist if you want me to dig back thru my notes on it. Rex -- 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
3420 old tapes
Hello: I have an oldie but a goodie. One of our user areas sent us 9 3420 tapes today, and some of them appear to be 800 BPI. When I run tape map against the tape I get the data in the attachment. I am trying to read these files on a 3420 tape drive, and when I put the density (DEN=2) into my JCL I get a 413-24 abend. I've tried various combinations and I cannot seem to get these old tapes to read, and without density IEBGENER gets a RC=12 for conflicting DCB info. I've also tried BLP and specifying the DCB parms directly, and still no luck. Does anyone have any suggestions as to how I can possibly get this to read on our tape drives, or is there a hardware setting on a 3420 that will make this possible? I looked in the archives and did not find anything specific about this, and this is a little before my time. 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 1VOL=007893 TAPE ANALYSIS PROGRAM (T A P E M A P) V2.1 TUESDAYMAY 06, 2008 (08.127) 15:09:34 RELOAD FILE PSWD INFO BLOCK BLOCKLNTH TOTL CREATOR FORMAT SEQ# DATASET NAME REQD C-DATE E-DATE SOURCE RECFM LRECL SIZE COUNT DEN TRT (FT) LNTH JOBNAME/STEPNAME 0 PW.PREV.ELPH . 00.000 LABELS S A CEN C DAT 95 TR INC 2SCAN F 1499 95 16001313 - *** EOV *** -* ONE OR MORE FILES HAVE DENSITY INDICATED INCORRECTLY IN LABELS. ALL FILES ARE WRITTEN AT 800 BPI * + 800 + 800 0NOTE: LENGTH(S) ARE COMPUTED, (BASED ON BLKSIZE, BLKCOUNT, AND DENSITY), AND ARE THEREFORE ONLY APPROXIMATE.
Re: VSAM / COBOL question - redux (fwd)
Aside from the fact that you might be improving their code :) I thought you engaged in the splitting exercise to separate Production from Development. If so, why is a Production file being shared at all. Make them make a copy. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don Leahy Sent: Tuesday, May 06, 2008 10:31 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) Yea, I gave them those references. They're gonna scream: I didn't need to do that in the PAST!!! sobwhinemoan Yes, you did. You just got lucky, and got away with not doing it. sound effect Washing hands. /sound effect The phrase I like to use is: Working By Coincidence. -- 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Tuesday, May 06, 2008 2:25 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) Aside from the fact that you might be improving their code :) I thought you engaged in the splitting exercise to separate Production from Development. If so, why is a Production file being shared at all. Make them make a copy. I totally agree with that idea. But I have been shot down many times. They feel that the absolutely MUST read the actual Production file. What they do, at times, is run a test job under their ID to extract production data. Once they have it working in test, then they create a production special job to actually extract the data to a production file for some other processing. But they don't want to test their code against the test data, they test against the production data. I guess so that they can be sure that it will actually run when presented with the data in the production file. Another reason is that management is not being penny foolish and demanding that any DASD allocations be justified. It is difficult to justify making a copy of production data for testing when the actual production data can be used instead. At least from what I understand. Again, I disagree with this philosophy. But I'm just a grunt. -- 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: VSAM / COBOL question - redux (fwd)
McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Tuesday, May 06, 2008 2:25 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) Aside from the fact that you might be improving their code :) I thought you engaged in the splitting exercise to separate Production from Development. If so, why is a Production file being shared at all. Make them make a copy. I totally agree with that idea. But I have been shot down many times. They feel that the absolutely MUST read the actual Production file. What they do, at times, is run a test job under their ID to extract production data. Once they have it working in test, then they create a production special job to actually extract the data to a production file for some other processing. But they don't want to test their code against the test data, they test against the production data. I guess so that they can be sure that it will actually run when presented with the data in the production file. Another reason is that management is not being penny foolish and demanding that any DASD allocations be justified. It is difficult to justify making a copy of production data for testing when the actual production data can be used instead. At least from what I understand. Again, I disagree with this philosophy. But I'm just a grunt. H. Memo to self: find out if healthmarkets is used by my insurer. If so, change insurers. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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: 3420 old tapes
What model of 3420 drive do you have? I am pretty sure at least the later models (4, 6, and 8) could only read 1600 or 6250 bpi. http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3420.html Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Todd Burrell Sent: Tuesday, May 06, 2008 2:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: 3420 old tapes Hello: I have an oldie but a goodie. One of our user areas sent us 9 3420 tapes today, and some of them appear to be 800 BPI. When I run tape map against the tape I get the data in the attachment. I am trying to read these files on a 3420 tape drive, and when I put the density (DEN=2) into my JCL I get a 413-24 abend. I've tried various combinations and I cannot seem to get these old tapes to read, and without density IEBGENER gets a RC=12 for conflicting DCB info. I've also tried BLP and specifying the DCB parms directly, and still no luck. Does anyone have any suggestions as to how I can possibly get this to read on our tape drives, or is there a hardware setting on a 3420 that will make this possible? I looked in the archives and did not find anything specific about this, and this is a little before my time. 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock Sent: Tuesday, May 06, 2008 2:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) H. Memo to self: find out if healthmarkets is used by my insurer. If so, change insurers. Hope nobody here read that. It could cost me my job. -- 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: VSAM / COBOL question - redux (fwd)
H. Memo to self: find out if healthmarkets is used by my insurer. If so, change insurers. Hope nobody here read that. It could cost me my job. Gotta be careful about what you air on these forums. I never gripe about bad practices by a current employer and mask the identity of any previous ones. (If you don't want it to be heard, don't say it) (If you don't want to to be read, don't write it) - 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: VSAM / COBOL question - redux (fwd)
It is difficult to justify making a copy of production data for testing when the actual production data can be used instead. At least from what I understand. Again, I disagree with this philosophy. But I'm just a grunt. What does your manager, SME, Auditor, compliance personell think of this arrangement? There are a lot of exposures to running test programmes against live Production data. Take last night's back-up, or run a regular copy job. If you're running a basic SYSPLEX, multiple image access can be problematic. You set it up to split prod from test. But, you implemented it in half-way measures. It's your shop, and you can do what you want, but I wouldn't want to run that way, or be a customer of a company that ran that way. - 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, May 06, 2008 2:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) Gotta be careful about what you air on these forums. I never gripe about bad practices by a current employer and mask the identity of any previous ones. (If you don't want it to be heard, don't say it) (If you don't want to to be read, don't write it) Good advice. I'll need to shut up for a while. -- 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: VSAM / COBOL question - redux (fwd)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock McKown, John wrote: -Original Message- From: IBM Mainframe Discussion ListOn Behalf Of Gibney, Dave Aside from the fact that you might be improving their code :) I thought you engaged in the splitting exercise to separate Production from Development. If so, why is a Production file being shared at all. Make them make a copy. I totally agree with that idea. But I have been shot down many times. They feel that the absolutely MUST read the actual Production file. What they do, at times, is run a test job under their ID to extract production data. Once they have it working in test, then they create a production special job to actually extract the data to a production file for some other processing. But they don't want to test their code against the test data, they test against the production data. I guess so that they can be sure that it will actually run when presented with the data in the production file. Another reason is that management is not being penny foolish and demanding that any DASD allocations be justified. It is difficult to justify making a copy of production data for testing when the actual production data can be used instead. At least from what I understand. Again, I disagree with this philosophy. But I'm just a grunt. H. Memo to self: find out if healthmarkets is used by my insurer. If so, change insurers. Indeed! One can only wonder how such a schema could pass a HIPAA audit. -jc- -- 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: APAR acronym
On Tue, 6 May 2008 13:10:57 +, john gilmore [EMAIL PROTECTED] wrote: The intent of my OP was to supply historical information, not to stir up bootless controversy. Controversy? Most of the comments have been light-hearted and/or a comment that it's been Authorized for 30 years or so. ... Let me also note that I stopped posting regularly in this forum chiefly because I found myself feeling and, worse, exhibiting less and less patience with the effluvia of gratuitous, because radically uninformed, responses that my posts too often elicited. ... Gratuitous? Well, we didn't charge for our comments. And they weren't solicited. But then, niether was your original post. Radically uninformed? I don't think so. I think we are fairly typically, customarily uninformed. Nothing radical there at all. ... I now regret breaching my silence on this occasion; and I shall in the future try to exhibit even greater restraint, limiting myself to an occasional éloge. ... Bye. 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: VSAM / COBOL question - redux (fwd)
On Tue, 6 May 2008 13:40:11 -0600, Steve Comstock [EMAIL PROTECTED] wrote: H. Memo to self: find out if is used by my insurer. If so, change insurers. No smiley? If John was banned from public postings (or worse) based on a posted comment like that, it would be a shame. If you were serious, you should have just kept that thought to yourself. 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 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: VSAM / COBOL question - redux (fwd)
I agree guys, everyone gets frustrated. It human nature. My opinions are my own and no one else's, but I am careful in regard to previous employers. It can backlash on you. Scott Ford Senior Host Developer | Forging Enterprise Identity | IdentityForge.com (Main) 678.266.3399 x304 | (Cell) 609.346.0399 | (Fax) 678.266.3399 [EMAIL PROTECTED] This message is for the designated recipient only and may contain priviledged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and then delete the original. Any other use of the email by you is prohibited. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, May 06, 2008 3:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, May 06, 2008 2:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) Gotta be careful about what you air on these forums. I never gripe about bad practices by a current employer and mask the identity of any previous ones. (If you don't want it to be heard, don't say it) (If you don't want to to be read, don't write it) Good advice. I'll need to shut up for a while. -- 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 -- 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: (Mainframe has competition was fwd) Re: COBOL Compiler for Windows
Last I heard, PULSE uses Tandem for the ATM's and uses a z/890 for the ancillary (balancing, posting, reporting) functions. If we look only at the 'clearing' function, then it is all z/os plus the usual assortment of tinkertoy servers. There might be a *nix or two in there somewhere. And has been so for at least 15 years. No plans to do anything differently except possibly moving the Tandem work to z/os. That software vendor offers ports to both platforms. I would guess that Pulse paid about $500k for their z/890. Maybe $1.2m as it sits today. Don't have the DASD prices handy, but I'd guestimate the total to be a little shy of $30m. Perhaps $27m shy :-) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark F Morris Sent: Sunday, May 04, 2008 6:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: (Mainframe has competition was fwd) Re: COBOL Compiler for Windows The following discussion on comp.lang.cobol may prove interesting. I would be curious to read if any of the major claims such as American Airlines Sabre moving totally to Unix are wrong. Clark Morris On Wed, 30 Apr 2008 22:38:36 -0500, in comp.lang.cobol Robert [EMAIL PROTECTED] wrote: On Wed, 30 Apr 2008 10:58:52 -0600, Howard Brazee [EMAIL PROTECTED] wrote: On Thu, 1 May 2008 02:56:51 +1200, Pete Dashwood [EMAIL PROTECTED] wrote: ...snip For example, PULSE, the largest ATM/EFT clearing system in the US, runs entirely on Unix servers. The base zSeries 990-332 machine, without disk and memory, costs around $15 million. If you had to beef it up with an appropriate amount of memory and disk, the mainframe hardware might cost $30 million. If you have to add monthly software fees for three years to this machine, it is probably on the order of $50 million for this machine over three years, including maintenance. Mainframes don't have list prices--which used to be against the law for IBM--so it is hard to say for sure. Even if you assume a 50 percent discount, after adding in the software costs, you are talking about $55 per TPM. That's a 10 to 1 price premium. And it will get worse as the Power6 and Power7 generations roll out, unless IBM consolidates the zSeries into one of these future Power-based servers. And that is why many people believe IBM will do just that, as it has already done with its proprietary OS/400-based servers. http://www.itjungle.com/tug/tug120204-story02.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 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: VSAM / COBOL question - redux (fwd)
Mark Zelden wrote: On Tue, 6 May 2008 13:40:11 -0600, Steve Comstock [EMAIL PROTECTED] wrote: H. Memo to self: find out if is used by my insurer. If so, change insurers. No smiley? If John was banned from public postings (or worse) based on a posted comment like that, it would be a shame. If you were serious, you should have just kept that thought to yourself. Mark I wasn't serious, the intent was to be chaffing as the British would say (or at least do say in the Somerset Maugham stories I'm currently re-reading). Anyway, I certainly did not intend any harm to John, and I've replied off list to him. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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: VSAM / COBOL question - redux (fwd)
If John was banned from public postings (or worse) based on a posted comment like that, it would be a shame. Unfortunately, John created the opportunity by exposing shortcomings where he works. Any public posting becomes fair game. See my previous post regarding ... If you don't want it to be read - 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: APAR acronym
The intent of my OP was to supply historical information, not to stir up bootless controversy. If I post a comment that contains a mis-remembered detail, I get lambasted regularly by two people (whom I now ignore). I try to be accurate and helpful, but some people don't care. They'd rather criticise and jump rather than constructively aid in seeking the truth. Why should you be treated better? Controversy? Most of the comments have been light-hearted and/or a comment that it's been Authorized for 30 years or so. I started in this business (professionally) in 1981. We were given a video presentation by the Toronto IBM Support Centre (ISC -- and, they did spell it that way in Canada). The first A in APAR stood for Authourised, back then. - 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: 3420 old tapes
We got rid of all of our 800 bpi tapes a long time ago- sometime around 1990 I think, because the new version of MVS we were installing at the time no longer supported 800 bpi. Since we had a major customer who required that support, we built a front-end read the tapes create a disk file job on VM. We ran that way for a year or so until our customer was able to upgrade to - 1600 bpi. I don't know if VM still supports 800 bpi or not. In any case, even if you have OS support, not all 3420 type tape drives can read all densities. We still have a few (at least we will have them a couple more months) 3420 type drives. Some are dual 1600/6250 bpi and some are 6250 only. What brand and model are your tape drives? How are they gened? Best of Luck, Linda Mooney -- Original message -- From: Todd Burrell [EMAIL PROTECTED] Hello: I have an oldie but a goodie. One of our user areas sent us 9 3420 tapes today, and some of them appear to be 800 BPI. When I run tape map against the tape I get the data in the attachment. I am trying to read these files on a 3420 tape drive, and when I put the density (DEN=2) into my JCL I get a 413-24 abend. I've tried various combinations and I cannot seem to get these old tapes to read, and without density IEBGENER gets a RC=12 for conflicting DCB info. I've also tried BLP and specifying the DCB parms directly, and still no luck. Does anyone have any suggestions as to how I can possibly get this to read on our tape drives, or is there a hardware setting on a 3420 that will make this possible? I looked in the archives and did not find anything specific about this, and this is a little before my time. 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 ---BeginMessage--- 1VOL=007893 TAPE ANALYSIS PROGRAM (T A P E M A P) V2.1 TUESDAYMAY 06, 2008 (08.127) 15:09:34 RELOAD FILE PSWD INFO BLOCK BLOCKLNTH TOTL CREATOR FORMAT SEQ# DATASET NAME REQD C-DATE E-DATE SOURCE RECFM LRECL SIZE COUNT DEN TRT (FT) LNTH JOBNAME/STEPNAME 0 PW.PREV.ELPH . 00.000 LABELS S A CEN C DAT 95 TR INC 2SCAN F 1499 95 16001313 - *** EOV *** -* ONE OR MORE FILES HAVE DENSITY INDICATED INCORRECTLY IN LABELS. ALL FILES ARE WRITTEN AT 800 BPI * + 800 + 800 0NOTE: LENGTH(S) ARE COMPUTED, (BASED ON BLKSIZE, BLKCOUNT, AND DENSITY), AND ARE THEREFORE ONLY APPROXIMATE. ---End Message---
Re: VSAM / COBOL question - redux (fwd)
It was my own thoughtlessness. I simply need to not post anything that somebody __might__ (in house or otherwise) cause me a problem. Live and learn, I guess. -- 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: Long running Batch programs keep IMS databases offline
It's been a decade or two, but concurrent batch/online was a base feature of IMS. Problems included the difficulty in backing out the effects of a malfunctioning batch program. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anne Lynn Wheeler Sent: Monday, May 05, 2008 11:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Long running Batch programs keep IMS databases offline The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. F [EMAIL PROTECTED] writes: We have IMS 9 on z/OS and I am fairly new to the platform and have a vested interest in fixing it. Every night we have batch programs that run which in return keeps our databases offline for a long time and as a result our applications are not available for processing. I want to know why batch programs and databases cannot both be online at the same time ? If the batch programs read the databases, then why are they offline ? Anyways, what are some ways of ensuring that batch jobs and databases can both run and be online at the same time ? some recent discussions about overnight batch window ... which requires exclusive access to all the information ... as opposed to online. http://www.garlic.com/~lynn/2008b.html#74 Too much change opens up financial fault lines http://www.garlic.com/~lynn/2008c.html#92 CPU time differences for the same job http://www.garlic.com/~lynn/2008d.html#30 Toyota Sales for 2007 May Surpass GM http://www.garlic.com/~lynn/2008d.html#31 Toyota Sales for 2007 May Surpass GM http://www.garlic.com/~lynn/2008d.html#73 Price of CPU seconds http://www.garlic.com/~lynn/2008d.html#87 Berkeley researcher describes parallel path http://www.garlic.com/~lynn/2008d.html#89 Berkeley researcher describes parallel path http://www.garlic.com/~lynn/2008g.html#55 performance of hardware dynamic scheduling http://www.garlic.com/~lynn/2008h.html#50 Microsoft versus Digital Equipment Corporation there were some number of efforts in the 90s (billions of dollars) that looked at business process re-engineering to leverage killer micros and distributed object-oriented technology to implement straight-through processing (eliminating the overnight batch window). It turns out that many of these had grandious failures when nobody bothered to do any speedsfeeds until very late in the effort ... frequently belatedly discovering that the distributed object-oriented technology had a factor of 100 times increase in overhead (compared to the typical Cobol batch implementation), totally obliterating any hopes of throughput improvements. -- 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 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: Long running Batch programs keep IMS databases offline
My knowledge of IMS is minimal but I seem to recall there being two flavors of IMS batch processing IMS DL/I was usually offline processing where files could not be accessed concurrently by the onlines IMS BMP (Batch Message Processing) was where the batch jobs accessed the data bases through message processing regions similar to online transaction processors so they could run concurrent with online. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: [EMAIL PROTECTED] DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/06/2008 04:09:35 PM: It's been a decade or two, but concurrent batch/online was a base feature of IMS. Problems included the difficulty in backing out the effects of a malfunctioning batch program. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anne Lynn Wheeler Sent: Monday, May 05, 2008 11:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Long running Batch programs keep IMS databases offline The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. F [EMAIL PROTECTED] writes: We have IMS 9 on z/OS and I am fairly new to the platform and have a vested interest in fixing it. Every night we have batch programs that run which in return keeps our databases offline for a long time and as a result our applications are not available for processing. I want to know why batch programs and databases cannot both be online at the same time ? If the batch programs read the databases, then why are they offline ? Anyways, what are some ways of ensuring that batch jobs and databases can both run and be online at the same time ? some recent discussions about overnight batch window ... which requires exclusive access to all the information ... as opposed to online. http://www.garlic.com/~lynn/2008b.html#74 Too much change opens up financial fault lines http://www.garlic.com/~lynn/2008c.html#92 CPU time differences for the same job http://www.garlic.com/~lynn/2008d.html#30 Toyota Sales for 2007 May Surpass GM http://www.garlic.com/~lynn/2008d.html#31 Toyota Sales for 2007 May Surpass GM http://www.garlic.com/~lynn/2008d.html#73 Price of CPU seconds http://www.garlic.com/~lynn/2008d.html#87 Berkeley researcher describes parallel path http://www.garlic.com/~lynn/2008d.html#89 Berkeley researcher describes parallel path http://www.garlic.com/~lynn/2008g.html#55 performance of hardware dynamic scheduling http://www.garlic.com/~lynn/2008h.html#50 Microsoft versus Digital Equipment Corporation there were some number of efforts in the 90s (billions of dollars) that looked at business process re-engineering to leverage killer micros and distributed object-oriented technology to implement straight-through processing (eliminating the overnight batch window). It turns out that many of these had grandious failures when nobody bothered to do any speedsfeeds until very late in the effort ... frequently belatedly discovering that the distributed object-oriented technology had a factor of 100 times increase in overhead (compared to the typical Cobol batch implementation), totally obliterating any hopes of throughput improvements. -- 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 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 -- 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: VSAM / COBOL question - redux (fwd)
On 6 May 2008 12:34:26 -0700, in bit.listserv.ibm-main you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Tuesday, May 06, 2008 2:25 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VSAM / COBOL question - redux (fwd) Aside from the fact that you might be improving their code :) I thought you engaged in the splitting exercise to separate Production from Development. If so, why is a Production file being shared at all. Make them make a copy. I totally agree with that idea. But I have been shot down many times. They feel that the absolutely MUST read the actual Production file. What they do, at times, is run a test job under their ID to extract production data. Once they have it working in test, then they create a production special job to actually extract the data to a production file for some other processing. But they don't want to test their code against the test data, they test against the production data. I guess so that they can be sure that it will actually run when presented with the data in the production file. Another reason is that management is not being penny foolish and demanding that any DASD allocations be justified. It is difficult to justify making a copy of production data for testing when the actual production data can be used instead. At least from what I understand. Again, I disagree with this philosophy. But I'm just a grunt. What does HIPAA (or whatever the spelling is) say about having test access to true production data? What does it say about having copies that are not obfuscated? -- 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: 3420 old tapes
I appreciate all of the replies. As I had figured, we're pretty much out of luck right now. We're going to try and figure out a way to get on a 3420 that can read 800 BPI, but we may still have an issue with OS releases, etc... We were trying to help out one of our customers, and this turned into a much bigger project that I ever thought it would be. No good deed ever goes unpunished... Thanks C. Todd Burrell Lead z/OS Systems Programmer ITSO (404) 723-2017 (Cell) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Linda Mooney Sent: Tuesday, May 06, 2008 4:08 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 3420 old tapes We got rid of all of our 800 bpi tapes a long time ago- sometime around 1990 I think, because the new version of MVS we were installing at the time no longer supported 800 bpi. Since we had a major customer who required that support, we built a front-end read the tapes create a disk file job on VM. We ran that way for a year or so until our customer was able to upgrade to - 1600 bpi. I don't know if VM still supports 800 bpi or not. In any case, even if you have OS support, not all 3420 type tape drives can read all densities. We still have a few (at least we will have them a couple more months) 3420 type drives. Some are dual 1600/6250 bpi and some are 6250 only. What brand and model are your tape drives? How are they gened? Best of Luck, Linda Mooney -- Original message -- From: Todd Burrell [EMAIL PROTECTED] Hello: I have an oldie but a goodie. One of our user areas sent us 9 3420 tapes today, and some of them appear to be 800 BPI. When I run tape map against the tape I get the data in the attachment. I am trying to read these files on a 3420 tape drive, and when I put the density (DEN=2) into my JCL I get a 413-24 abend. I've tried various combinations and I cannot seem to get these old tapes to read, and without density IEBGENER gets a RC=12 for conflicting DCB info. I've also tried BLP and specifying the DCB parms directly, and still no luck. Does anyone have any suggestions as to how I can possibly get this to read on our tape drives, or is there a hardware setting on a 3420 that will make this possible? I looked in the archives and did not find anything specific about this, and this is a little before my time. 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: Long running Batch programs keep IMS databases offline
It's been a decade or two, but concurrent batch/online was a base feature of IMS. Problems included the difficulty in backing out the effects of a malfunctioning batch program. It's called BMP -- Batch Message Programming. Instead of going against the database directly, the Batch job talks to the IMS control region. My understanding (I am not an IMS application programmer, nor do I play one on TV) is that there is little effort required to convert Batch offline to BMP processing, but an expert would have to confirm. Also, there is the crude approach of processing against a copy of the database. If it weren't moribund, I would suggest posting the question on IMS-L. I have been a subscriber over there for years, since I have only (for three years) once worked at a non-IMS shop. I haven't seen a posting from it in a long time. - 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: Connect:Direct (NDM) CPU Usage
An early foray into file encryption showed this behavior, IIRC. Some enciphering algorithms are said to be really heavy CPU hitters. If you are encrypting then you need to be careful with compression. Encrypted data is said to be generally not compressible. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kelman, Tom Sent: Friday, May 02, 2008 10:53 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Connect:Direct (NDM) CPU Usage We run Connect:Direct (used to be called NDM) from Sterling Commerce. Yesterday afternoon the started task, CDNDM, took from 50-60% of an engine on our z9BC for almost 2 hours while it transferred a large file. This caused us to hit our softcap and affected other tasks in the system. We have the CDNDM task running in our STCLO service class which is set for Vel=50 and an importance level of 4. It was still running at a high DP and grabbed the CPU. I can't understand why a task that is basically transmitting a file over the network should need this much CPU. My only explanation might be that it is compressing the data before putting it on the network and the compression algorithm isn't the most efficient in the world. Has anyone else had this kind of a problem running Connect:Direct? What, if anything, did you do to control it? Tom Kelman Commerce Bank of Kansas City (816) 760-7632 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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 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: Connect:Direct (NDM) CPU Usage
If you are encrypting then you need to be careful with compression. Encrypted data is said to be generally not compressible. Compress first. Then encrypt. If I recall from my basic computer courses in the mid-1970's. - 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
