Re: Need to cap my software costs
Some people activate a Coupling Facility LPAR with a z/OS CP in dyndisp=no mode: its weight represents the number MSU which you want consume without billing because these MSUs doesn't enter in the SW bill. As all functions of capping, it's a technical way. You need to search for a financial way. Jacky Hofbauer zCost Management There are risks and costs to a program of action, but they are far less than the long-range risks and costs of comfortable inaction. John F. Kennedy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Why would I use System REXX as shown in the sample? (was: RO command query)
If this is only system REXX issue, there is an example of using AXRMLWTO in the MVS Authorized Assembler Services Guide: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A881/31. 5?SHELF=IEA2BK81DT=20080120225118 While we're at it: I once more tried to understand the advantage of using System REXX in general and especially as shown in the MCSOPER example. There is an asm routine establishing an EMCS console, then calling System REXX to issue a system command, retrieving the command response and writing it back to our previously established EMCS console, finally the assembler code, after returning from System REXX reads the command response from the EMCS console. Seems like a lot of overhead and a lot more complex than necessary to me. Why not simply issue the command directly from the asm code (using MGCRE)? What (advantage) am I missing? Is anybody using System REXX? If so, what for? -- Peter Hunkeler Credit Suisse -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Shell Scripts in EKM
The reason is our EMK server on z/OS V1.9 does not have any message IDs, so all we get is the following text: Server is running. TCP port: 3801, SSL port: 1443 Seems like inacceptable behaviour for a software to be run on z/OS. I'd try to open a PMR requesting identifiable messages. -- Peter Hunkeler Credit Suisse -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Shell Scripts in EKM
I have already done that. A requirements hasw been accepted. But with ported applications I am not sure how long it will take for IBM to action this. Not enough z/OS Users or tape encryption to put pressure on sooner than later. So in the meantime, I am hoping a shell script could be created that will give us the message we need for automation. Lizette The reason is our EMK server on z/OS V1.9 does not have any message IDs, so all we get is the following text: Server is running. TCP port: 3801, SSL port: 1443 Seems like inacceptable behaviour for a software to be run on z/OS. I'd try to open a PMR requesting identifiable messages. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cobol and variable record length RRDS files
Here is the code I use to get the length of a variable rrds record DATA DIVISION. FILE SECTION. FD TLCMST RECORD IS VARYING FROM 879 TO 1679 CHARACTERS DEPENDING ON TLCMST-LENGTH. COPY TLCMST. - - - - - - - - - - - - - 20 Line(s) not Displayed 01 WORK-FLDS1 COMP-3. - - - - - - - - - - - - - 12 Line(s) not Displayed 05 TLCMST-LENGTHPIC 9(5) VALUE . the tlcmst-length will have the lenght from the record descriptor word. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Syncsort Oddity
Hi, I’ve encountered something in Syncsort, and I’m looking for an explanation. One of our users used Syncsort to copy a dataset. The input file had 93386 tracks in 10 extents. The output file had 64815 tracks in 2 extents. Both files are LRECL=27904 BLKSIZE=27998 RECFM=VB DSNTYPE=LARGE. The copy job used Syncsort’s SDB=ON option Both are allocated on the same type of DASD (3390-54). When we say the 30% difference in size we used IEBCOMPR to compare the two file, and the result was that they were identical. Another test was done. This time, Syncsort was used to copy records that had a specific value in a specific field. On the large (Input) file, the job ran for 64 seconds. On the small (Output) file the same operation took 7 seconds. Can anyone explain this? TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
On Wed, 31 Dec 2008 13:56:20 +0200 ??? ?? ??? gad...@malam.com wrote: :Ive encountered something in Syncsort, and Im looking for an explanation. :One of our users used Syncsort to copy a dataset. :The input file had 93386 tracks in 10 extents. :The output file had 64815 tracks in 2 extents. :Both files are LRECL=27904 BLKSIZE=27998 RECFM=VB DSNTYPE=LARGE. :The copy job used Syncsorts SDB=ON option :Both are allocated on the same type of DASD (3390-54). :When we say the 30% difference in size we used IEBCOMPR to compare the two file, and the result was that they were identical. :Another test was done. This time, Syncsort was used to copy records that had a specific value in a specific field. On the large (Input) file, the job ran for 64 seconds. On the small (Output) file the same operation took 7 seconds. :Can anyone explain this? I would look at the raw input file and see how it was blocked. Perhaps the program that created the file wrote smaller blocks. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
Gadi, May Syncsort truncate the record if trailing x'00'' or blanks are padded at end of some of the records? I would look into the shorter records in the file to see if they are realy shorter... Itschak 2008/12/31 גדי בן אבי gad...@malam.com Hi, I've encountered something in Syncsort, and I'm looking for an explanation. One of our users used Syncsort to copy a dataset. The input file had 93386 tracks in 10 extents. The output file had 64815 tracks in 2 extents. Both files are LRECL=27904 BLKSIZE=27998 RECFM=VB DSNTYPE=LARGE. The copy job used Syncsort's SDB=ON option Both are allocated on the same type of DASD (3390-54). When we say the 30% difference in size we used IEBCOMPR to compare the two file, and the result was that they were identical. Another test was done. This time, Syncsort was used to copy records that had a specific value in a specific field. On the large (Input) file, the job ran for 64 seconds. On the small (Output) file the same operation took 7 seconds. Can anyone explain this? TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Shell Scripts in EKM
Yes, it is in the manual. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Tuesday, December 30, 2008 8:17 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Shell Scripts in EKM Dave, Where is that documented? Is it in a manual? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jousma, David Sent: Tuesday, December 30, 2008 2:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Shell Scripts in EKM Lizette, You didn’t ask for it, but you might also want something like the following job. It is really the only way to prove that a tape is encrypted. It runs a supplied java program that lists all the tapes that have been encrypted. //STEP3 EXEC PGM=IKJEFT1B //SYSEXEC DD DSN=SYS1.SBPXEXEC,DISP=SHR //SYSTSPRT DD SYSOUT=* //SYSTSIN DD *,DLM=$$ OSHELL java com.ibm.keymanager.tools.EKMDataParser -filename+ This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why would I use System REXX as shown in the sample? (was: RO command query)
On Wed, 31 Dec 2008 09:38:36 +0100, Hunkeler Peter (KIUK 3) peter.hunke...@credit-suisse.com wrote: Samples are just that. They aren't indicative of the best way to do something. But good samples are better than bad samples. :-) What (advantage) am I missing? Being able to execute the process from an operator console as if it were a built-in operator command. Even if you can't get onto TSO.I'm talking in general terms here... not in reference to that sample in particular since I didn't look at it closely. Is anybody using System REXX? If so, what for? Not really.. only played with it. I am using a EXTSO exec to be able to issue a TSO command from the console. This is same thing Ed Jaffe was doing with TSOCMD (I think that is what he called it) ... or TSOX. Search the archives. It could be used for health checks. There have been some SHARE sessions on this. Personally, until there is a supported / alternate STORAGE function that I can use, I probably won't be doing much with it.Console automation packages can be used instead. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
On Tue, 30 Dec 2008 16:16:25 -0600, Don Higgins d...@higgins.net wrote: Here is something new and something old for 2009. Come to SHARE session 8194 in Austin TX on March 3, 2009 at 8 AM for the first live demonstration of zcobol portable mainframe COBOL compiler which is written in z390 structured conditional macro assembler. zcobol supports multiple dialects of mainframe COBOL with the option to generate source and executable program code in any one of the following target languages: 1. HLASM compatible mainframe assembler for z390/z9/z10 2. Java for any J2SE platform Does this mean that it might be possible to use zcobol to compile some of our current z/OS COBOL programs into Java classes and run them on a zAAP? 3. C++ for Windows platforms 4. HLA/MASM assembler for Intel platforms snip Don Higgins d...@higgins.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
I would look at the raw input file and see how it was blocked. Perhaps the program that created the file wrote smaller blocks. The OP did say they both had the same block size. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Bug or feature ? (ICSF)
I found discrepancy between ICSF documenation and reality. Documentation says: When KGUP generates a key, the program also generates information to create the complementary key. This information includes the complementary key value. The value is either a clear key value or encrypted key value. And it is true for encrypted keys only. For clear keys no statement is generated. Caution: I mean CSFSTMNT dataset entry. CSFKEYS entry is created in both cases. Q1: Did anyone notice similar issue? Maybe it depends on some details? Q2: Is it bug in program or documentation error? Happy New Year -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why would I use System REXX as shown in the sample? (was: RO command query)
I agree with the STORAGE function being required for SYSREXX to be useful. Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Wednesday, December 31, 2008 9:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Why would I use System REXX as shown in the sample? (was: RO command query) On Wed, 31 Dec 2008 09:38:36 +0100, Hunkeler Peter (KIUK 3) peter.hunke...@credit-suisse.com wrote: Samples are just that. They aren't indicative of the best way to do something. But good samples are better than bad samples. :-) What (advantage) am I missing? Being able to execute the process from an operator console as if it were a built-in operator command. Even if you can't get onto TSO.I'm talking in general terms here... not in reference to that sample in particular since I didn't look at it closely. Is anybody using System REXX? If so, what for? Not really.. only played with it. I am using a EXTSO exec to be able to issue a TSO command from the console. This is same thing Ed Jaffe was doing with TSOCMD (I think that is what he called it) ... or TSOX. Search the archives. It could be used for health checks. There have been some SHARE sessions on this. Personally, until there is a supported / alternate STORAGE function that I can use, I probably won't be doing much with it.Console automation packages can be used instead. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of ??? ?? ??? Sent: Wednesday, December 31, 2008 5:56 AM To: IBM-MAIN@bama.ua.edu Subject: Syncsort Oddity Hi, =20 I=92ve encountered something in Syncsort, and I=92m looking for an = explanation. =20 One of our users used Syncsort to copy a dataset. The input file had 93386 tracks in 10 extents. The output file had 64815 tracks in 2 extents. Both files are LRECL=3D27904 BLKSIZE=3D27998 RECFM=3DVB = DSNTYPE=3DLARGE. The copy job used Syncsort=92s SDB=3DON option =20 Both are allocated on the same type of DASD (3390-54).=20 When we say the 30% difference in size we used IEBCOMPR to compare the = two file, and the result was that they were identical. SNIP I know that you have said RECFM=VB. But, is it possible that Syncsort is writing short blocks to make use of otherwise wasted space on a track? I'm asking because we have run into a similar problem and I do not have access to the DASD in question to do track dumps. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
Use SAS to find the actual physical block size of the two files: // EXEC SAS //FILEONE DD DSN=FILEONE,DISP=SHR //FILETWO DD DSN=FILETWO,DISP=SHR //SYSIN DD * DATA SIZEONE; INFILE FILEONE RECFM=U BLKSIZE=32760 LENGTH=LEN; INPUT; LENGTH=LEN; PROC FREQ: TABLES LENGTH; TITLE TABULATION OF BLOCK SIZES IN FIRST FILE; DATA SIZETWO; INFILE FILETWO RECFM=U BLKSIZE=32760 LENGTH=LEN; INPUT; LENGTH=LEN; PROC FREQ: TABLES LENGTH; TITLE TABULATION OF BLOCK SIZES IN SECOND FILE; By specifying RECFM=U, SAS will read each block and store its physical length in temporary LEN variable with the LENGTH=LEN option, and then LENGTH=LEN; statement will create kept variable LENGTH, which is then tabulated by the PROC FREQ. Barry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barry Merrill Sent: Wednesday, December 31, 2008 9:30 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Syncsort Oddity Use SAS to find the actual physical block size of the two files: SNIP And for those of us that do not have SAS, you can use IDCAMS: //IDCAMS EXEC PGM=IDCAMS //SYSUT1 DD DISP=SHR,DSN=??, // DCB=(RECFM=U,LRECL=32760) //SYSPRINT DD SYSOUT=* //SYSINDD * PRINT DUMP IFILE(SYSUT1) COUNT(?) /* // Where you replace the ?? with the actual DSN and the ? with the number of blocks you are willing to look at. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Attachmate Extra! Toolbar editor - Usage assistance
Peter FYI - I did some 'playing' around and was working with the Quick Pads editor, which is MUCH more robust (you can alter the size of buttons and move ANYWHERE you'd like...), and created a quick pad with the customized items I wanted from the items in that 'other' customized toolbar which I was unable to edit via the toolbar editor and arranged the buttons in the way I wanted. (whew, long winded sentence there). After doing that and then displaying the new quick pad in my 3270 session I was looked at it and thot, dang, wish I could make this a toolbar so it was so abtrusive looking. Well, long story short... I went into My Computer and changed the extension for the new quick pad I had just created (.EQP) to the extension of the toolbars (.ETB) and viola! it was now a toolbar! So... use the far better Quick Pad editor to create/modify your buttons as you see fit and then to make it a toolbar just change the file extention to .ETB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
On Wed, 31 Dec 2008 15:00:35 + Ted MacNEIL eamacn...@yahoo.ca wrote: :I would look at the raw input file and see how it was blocked. Perhaps the program that created the file wrote smaller blocks. :The OP did say they both had the same block size. The same maximum block size. Not necessarily the same sizes for specific blocks. :Too busy driving to stop for gas! Yes, you were. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
new lpar
Thanks to anyone and everyone in advance. I am trying to build a new test lpar and running into an issue. I have created a new iocp and performed an activation and ipl of this new lpar. The new lpar appears to ipl but the console is being sent to the SE console. I deactivated the other lpar on the z9 I am trying to build this new lpar on and then reipled the new test lpar and the ipl is still being sent to the SE console. I obviously have not set something up correctly concerning the console but I cannot determine what it is. Can anyone offer any suggestions? Thanks, Kurt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
The same maximum block size. Not necessarily the same sizes for specific blocks. Eh? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: new lpar
On Wed, 31 Dec 2008 10:34:36 -0800, Kurt Eastwood kurtms...@yahoo.com wrote: Thanks to anyone and everyone in advance. I am trying to build a new test lpar and running into an issue. I have created a new iocp and performed an activation and ipl of this new lpar. The new lpar appears to ipl but the console is being sent to the SE console. I deactivated the other lpar on the z9 I am trying to build this new lpar on and then reipled the new test lpar and the ipl is still being sent to the SE console. I obviously have not set something up correctly concerning the console but I cannot determine what it is. Can anyone offer any suggestions? Thanks, Kurt Sounds like the new LPAR does not have any I/O connection to any of your defined consoles. What type of console controller are you using to drive your consoles? Is that device EMIF capable (old style 3174 controllers are not!)? We use Visara devices and it works fine. However they do require customization to be aware of any new LPAR connections. On a z9, I think it is possible to have an OSA-ICC set up. That device doesn't drive real consoles, but instead relies on a PC running a TN3270 emulator. We don't do this, so I don't know any more about it. Let me be the first to wish everybody a safe and sane 4th of July! (offer only applies to residents of the United States. Offer void where prohibited by law. You mileage may vary.) -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: new lpar
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown [ snip ] Let me be the first to wish everybody a safe and sane 4th of July! Little late, aren't you? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: new lpar
Nah, he might actually be the first - it's 7 months away. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John Sent: Wednesday, December 31, 2008 12:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: new lpar -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown [ snip ] Let me be the first to wish everybody a safe and sane 4th of July! Little late, aren't you? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
When using VB, some code will write a short block if the space remaining in the current block is less than the DCB LRECL, even though the actual length of the next record is unknown. This results in a lot of short blocks, particularly when the LRECL is large, as in this case. Ted MacNEIL eamacn...@yahoo.ca 12/31/2008 1:35 PM The same maximum block size. Not necessarily the same sizes for specific blocks. Eh? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
On Wed, 31 Dec 2008 18:35:20 +, Ted MacNEIL wrote: The same maximum block size. Not necessarily the same sizes for specific blocks. Eh? Ever heard of TRUNC? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
When using VB, some code will write a short block if the space remaining in the current block is less than the DCB LRECL, even though the actual length of the next record is unknown. This results in a lot of short blocks, particularly when the LRECL is large, as in this case. So, SYNCSORT 'repairs' this? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
On Wed, 31 Dec 2008 13:56:20 +0200, #1490;#1491;#1497; amp;#1489;#1503; #1488;#1489;#1497; gad...@malam.com wrote: Ive encountered something in Syncsort, and Im looking for an explanation. One of our users used Syncsort to copy a dataset. The input file had 93386 tracks in 10 extents. The output file had 64815 tracks in 2 extents. Both files are LRECL=27904 BLKSIZE=27998 RECFM=VB DSNTYPE=LARGE. Could it be that the space on the track is being used inefficiently because most of the records are about half of the buffer size? Syncsort might be smart enough to write short blocks when it knows that there is not room for a full block at the end of a track, improving utilization. Just a wild guess. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Boxed Devices Ate My Job
Our IMS system periodically submits batch jobs to offload its logs. Of course the job never fails until we run for 9 days unattended over the Christmas break. Some unexplained event caused the twin fiber links to our VTS to drop offline for about 10 minutes, generating sticky messages IOS581E and IOS208I. The rub then comes that the system generates messages IOS102I and IOS451I and boxes the device when the paths come online. Then some time later IMS submits his batch job which fails with a JCL error due to allocation failure because all 64 virtual tape drives have been boxed. No amount of COND=... will help for a JCL error so the email and text message alerts were never sent. Suggestions for automation or notification? (MPFLST only) Automatically vary the boxed device back online? Ben Alford Enterprise Systems Programming University of Tennessee -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Boxed Devices Ate My Job
If you have some sort of automation package like Mainview for IMS or AutoOperator, you could have it change your archive job to use DASD rather than tape when it sees your VTS's go boxed. Then your IMS's don't go belly up because they ran out of OLDS, and your archives don't get backed up either. Norris Jackson The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this message in error, please contact the sender and delete the material from all computers. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ben Alford Sent: Wednesday, December 31, 2008 1:11 PM To: IBM-MAIN@bama.ua.edu Subject: Boxed Devices Ate My Job Our IMS system periodically submits batch jobs to offload its logs. Of course the job never fails until we run for 9 days unattended over the Christmas break. Some unexplained event caused the twin fiber links to our VTS to drop offline for about 10 minutes, generating sticky messages IOS581E and IOS208I. The rub then comes that the system generates messages IOS102I and IOS451I and boxes the device when the paths come online. Then some time later IMS submits his batch job which fails with a JCL error due to allocation failure because all 64 virtual tape drives have been boxed. No amount of COND=... will help for a JCL error so the email and text message alerts were never sent. Suggestions for automation or notification? (MPFLST only) Automatically vary the boxed device back online? Ben Alford Enterprise Systems Programming University of Tennessee -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
At 14:22 +0200 on 12/31/2008, Binyamin Dissen wrote about Re: Syncsort Oddity: On Wed, 31 Dec 2008 13:56:20 +0200 ??? ?? ??? gad...@malam.com wrote: :I¹ve encountered something in Syncsort, and I¹m looking for an explanation. :One of our users used Syncsort to copy a dataset. :The input file had 93386 tracks in 10 extents. :The output file had 64815 tracks in 2 extents. :Both files are LRECL=27904 BLKSIZE=27998 RECFM=VB DSNTYPE=LARGE. :The copy job used Syncsort¹s SDB=ON option :Both are allocated on the same type of DASD (3390-54). :When we say the 30% difference in size we used IEBCOMPR to compare the two file, and the result was that they were identical. :Another test was done. This time, Syncsort was used to copy records that had a specific value in a specific field. On the large (Input) file, the job ran for 64 seconds. On the small (Output) file the same operation took 7 seconds. :Can anyone explain this? I would look at the raw input file and see how it was blocked. Perhaps the program that created the file wrote smaller blocks. Was the original file created in one pass or was it updated over a number of runs? If the later then the problem may be that each time you open file, you start with a new block in lieu of reading the last block, extending it, and then rewriting the larger block before starting a new block. There is also the possibility that the Syncsort keeps track of the remaining space on the track and flushes the buffer as soon as the next record would force the block to be longer than the remaining room. IOW: You have 2000 bytes left on the track and can write a 1900 byte record so you do so in lieu of waiting until the block is ~27998 bytes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Boxed Devices Ate My Job
Hi Ben, We don't have IMS, but we do have other tasks that submit jobs, so pehaps this method will be helpful - it works well for us. We have the submitted JCL IEFBR14 allocate and catalog a dataset instead of running the 'real' job. We tell our scheduling system (ZEKE) to submit a job (in this case the one that would do the log cleanup) when it 'sees' that dataset catalogued. One of ZEKE's features is that it checks to see if the devices needed to run the job are available. If not, then ZEKE can trigger a notification of whoever would need to take care of the problem. For us, ZEKE notifies a DBA by text message to a cell phone if a specific database job can't run while we are unattended. If you don't have ZEKE, it's likely that you could do the same sort of thing with your scheduling system. We don't have any automated ops either. Linda Mooney -- Original message -- From: Ben Alford pa7...@utkvm1.utk.edu Our IMS system periodically submits batch jobs to offload its logs. Of course the job never fails until we run for 9 days unattended over the Christmas break. Some unexplained event caused the twin fiber links to our VTS to drop offline for about 10 minutes, generating sticky messages IOS581E and IOS208I. The rub then comes that the system generates messages IOS102I and IOS451I and boxes the device when the paths come online. Then some time later IMS submits his batch job which fails with a JCL error due to allocation failure because all 64 virtual tape drives have been boxed. No amount of COND=... will help for a JCL error so the email and text message alerts were never sent. Suggestions for automation or notification? (MPFLST only) Automatically vary the boxed device back online? Ben Alford Enterprise Systems Programming University of Tennessee -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to calculate size of a PS dataset (no, no yet again)
In 000801c9670e$3b559f80$b200de...@hawkins1960@sbcglobal.net, on 12/25/2008 at 07:58 PM, Ron Hawkins ron.hawkins1...@sbcglobal.net said: So what is your answer to the question? The one that I posted: use, e.g., BLK3390 to determine how many blocks will fit on a track, then do the arithmetic. That assumes, of course, no compression and no short blocks. The OP did not ask how much to allocate - he asked how much is allocated. The answer is the same, i.e., determine the number of blocks/track and do the arithmetic. Factors for block gaps and end-of-track waste are already factored into the existing file allocation. Not if the original allocation was in tracks or cylinders. Not if there are secondary extents. Besides which, if the original poster had the original allocation in, e.g., Mi bytes, then he wouldn't be asking. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Find CLASS and MSGCLASS
In cd427cf50812300153s3547f9f5h3403f31ac885f...@mail.gmail.com, on 12/30/2008 at 03:23 PM, Yogeetha balasubramanian sairamyog...@gmail.com said: I have always thought about finding the class and the msgclass myself for creating our own jobcard. Do someone know how to find them ? MSGCLASS is inherited. In general you need to find out what your installation standards call for, which may not be the same as for the submitting job. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Find CLASS and MSGCLASS
In listserv%200812301235128694.0...@bama.ua.edu, on 12/30/2008 at 12:35 PM, Paul Gilmartin paulgboul...@aim.com said: Wouldn't it be nice if, like the USERID, default OUTPUT parameters (CLASS, DEST, FORMS, etc.) were inherited from the submitting job? Not only would it be nice, but some of them *are* inherited. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
2008/12/31 John McKown joa...@swbell.net: On Tue, 30 Dec 2008 16:16:25 -0600, Don Higgins d...@higgins.net wrote: Here is something new and something old for 2009. Come to SHARE session 8194 in Austin TX on March 3, 2009 at 8 AM for the first live demonstration of zcobol portable mainframe COBOL compiler which is written in z390 structured conditional macro assembler. zcobol supports multiple dialects of mainframe COBOL with the option to generate source and executable program code in any one of the following target languages: 1. HLASM compatible mainframe assembler for z390/z9/z10 2. Java for any J2SE platform Does this mean that it might be possible to use zcobol to compile some of our current z/OS COBOL programs into Java classes and run them on a zAAP? Heh heh heh... The specialty engine can o' worms arises yet again. I have no doubt that IBM has applied people much smarter than I am and equipped with all the best tools, to this situation, because it has been inevitable that someone would produce a COBOL to Java compiler (whether the compiler output is Java source, or JVM bytecodes) just to exploit this situation. I believe there are a couple of existing commercial offerings along these lines, but they are probably geared to running COBOL on non-mainframe platforms, and don't really provide any threat of moving workload from regular (expensive) z engines to specialty (cheap) ones. But here comes a compiler that is written by mainframe knowledgable people, with a clear understanding of what's needed for such a transition, including the supporting environment items like CICS. My guess is that IBM won't do anything at the moment, because zcobol is probably too difficult for production shops to use, and isn't (yet?) supported in the way that big commercial users would require. And of course there's the performance question. But clearly IBM does have a problem if it becomes fairly easy to move existing (dare I say legacy?) workload to a cheaper and maybe even faster engine. All of the specialty engines types except zAAP have technological and contractual means of restricting their use to the IBM-desired new workloads. But an engine that runs Java by design in order to attract new work (hopefully from Sun or HP boxes) can't really look at your JVM bytecodes and say this looks like something that was originally written in COBOL so we won't run it, any more than an airline can say you look like a business traveller, so we'll charge you five times the rate your seatmates are paying for this flight. My wild guess is that if zcobol looks like a real threat, IBM will just buy it. And maybe that wouldn't be such a bad thing from its developer's point of view... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
REXX STORAGE (was: Why would I use System REXX as shown in the sample? (was: RO command query))
On Wed, 31 Dec 2008 08:42:26 -0600, Mark Zelden mark.zel...@zurichna.com wrote: ... Personally, until there is a supported / alternate STORAGE function that I can use, I probably won't be doing much with it.Console automation packages can be used instead. ... I know this is the wrong forum to discuss this, but ... I've never understood that part of IRXINIT that uses a 1-bit flag (STORFL) to control use of the STORAGE function - full read/write function or none. I can understand needeing (or at least wanting) to prevent writing using STORAGE - especially in a multi-user address space, but there should be a read-only option vailable. Yes, I know STORAGE is an external function so it would require cooperation of that external function, but the environment executing IRXINIT is the same one providing the external function. It should know whether a read-only STORAGE function is provided. I'm too near the end of my career to see this situation change, but younger folk might consider submitting a Requirement Same comment goes for System REXX.Submit a Req that the STORAGE function be enabled for System REXX. At the very least, let it be an an installation option controlled by a PARMLIB member or some such. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: new lpar
On Wed, 31 Dec 2008 10:34:36 -0800, Kurt Eastwood kurtms...@yahoo.com wrote: Thanks to anyone and everyone in advance. I am trying to build a new test lpar and running into an issue. I have created a new iocp and performed an activation and ipl of this new lpar. The new lpar appears to ipl but the console is being sent to the SE console. I deactivated the other lpar on the z9 I am trying to build this new lpar on and then reipled the new test lpar and the ipl is still being sent to the SE console. I obviously have not set something up correctly concerning the console but I cannot determine what it is. Can anyone offer any suggestions? Is the console address in your NIPCONS? In HCD terms, that is in the OS config you IPLed with and defined via Work with consoles. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
And if you don't have SAS, user SYNCSORT's HISTOGRM program to get a distribution of block sizes. // EXEC PGM=HISTOGRM //SYSUT1 DD DISP=SHR, // DSN= //SYSPRINT DD SYSOUT=* Bob Barry Merrill wrote: Use SAS to find the actual physical block size of the two files: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
Both files are LRECL=27904 BLKSIZE=27998 RECFM=VB DSNTYPE=LARGE Unless it's a typo BLKSIZE=27998 is 90 bytes more than needed for VB LRECL 27904. Yet another factor. I would expect Syncsort to correct most of the possibilities already discussed. Dave Gibney Information Technology Services Washington State Univsersity -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert A. Rosenberg Sent: Wednesday, December 31, 2008 12:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Syncsort Oddity At 14:22 +0200 on 12/31/2008, Binyamin Dissen wrote about Re: Syncsort Oddity: On Wed, 31 Dec 2008 13:56:20 +0200 ??? ?? ??? gad...@malam.com wrote: :I¹ve encountered something in Syncsort, and I¹m looking for an explanation. :One of our users used Syncsort to copy a dataset. :The input file had 93386 tracks in 10 extents. :The output file had 64815 tracks in 2 extents. :Both files are LRECL=27904 BLKSIZE=27998 RECFM=VB DSNTYPE=LARGE. :The copy job used Syncsort¹s SDB=ON option :Both are allocated on the same type of DASD (3390-54). :When we say the 30% difference in size we used IEBCOMPR to compare the two file, and the result was that they were identical. :Another test was done. This time, Syncsort was used to copy records that had a specific value in a specific field. On the large (Input) file, the job ran for 64 seconds. On the small (Output) file the same operation took 7 seconds. :Can anyone explain this? I would look at the raw input file and see how it was blocked. Perhaps the program that created the file wrote smaller blocks. Was the original file created in one pass or was it updated over a number of runs? If the later then the problem may be that each time you open file, you start with a new block in lieu of reading the last block, extending it, and then rewriting the larger block before starting a new block. There is also the possibility that the Syncsort keeps track of the remaining space on the track and flushes the buffer as soon as the next record would force the block to be longer than the remaining room. IOW: You have 2000 bytes left on the track and can write a 1900 byte record so you do so in lieu of waiting until the block is ~27998 bytes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FW: Syncsort Oddity
This was supposed to go to the IBM-MAIN, not assembler list. Sorry about that. -Original Message- From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Bill Klein Sent: Wednesday, December 31, 2008 11:33 AM To: assembler-l...@listserv.uga.edu Subject: Fw: Syncsort Oddity If, for example, the original file were created by a COBOL program that was compiled with the NOAWO option (or the older OS/VS COBOL apply write only syntax), then it is QUITE possible that there are many short blocks in a VB file. When NOAWO is in effect for a COPY program, COBOL writes a block and starts a new one when the next record to be written COULD be large enough not to fit into the same block (if it were the maximum record size). With AWO in effect, COBOL actually waits to see how large the next record is an if it can it places it in the current block. Only if the ACTUAL next record won't fit in the existing block does the current block get written and a new block gets started. FOR COBOL programs that have a few very large records (such as header records) but mostly small records, the difference between AWO and NOAWO is SIGNIFICANT. I assume, but may be mistaken, that other types of applications besides COBOL NOAWO ones may have the same issue. Ted MacNEIL eamacn...@yahoo.ca wrote in message news:2016031228-1230735623-cardhu_decombobulator_blackberry.rim.net-1494412 2...@bxe348.bisx.prod.on.blackberry... I would look at the raw input file and see how it was blocked. Perhaps the program that created the file wrote smaller blocks. The OP did say they both had the same block size. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
On Wed, 31 Dec 2008 19:16:43 +, Ted MacNEIL eamacn...@yahoo.ca wrote: When using VB, some code will write a short block if the space remaining in the current block is less than the DCB LRECL, even though the actual length of the next record is unknown. This results in a lot of short blocks, particularly when the LRECL is large, as in this case. So, SYNCSORT 'repairs' this? Any properly written application should repair it, if I remember RECFM=V processing correctly. The LRECL value in the DCB tells you the maximum logical record length. If, when you go to write a logical record, the current data in the block + DCBLRECL is greater than the DCB block size, the access method will truncate the block. As I remember you're supposed to change DCBLRECL to reflect the actual size of the logical record you're about to write, and then the access method can properly fill the block. If you don't update DCBLRECL then if DCBLRECL is close to the blocksize (as it is in the OP's case) and significantly larger than the real LRECLs in the data set, then you could end up with a significant number of unexpectedly short blocks. Presumably SYNCSORT handles all this properly, and so you get optimal blocking, and take fewer tracks than a data set written with less than optimal blocking. Note that these are very old memories... And I know nothing about SYNCSORT. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBM Debug Tool in pure batch
I'm trying to use the IBM Debug Tool to list some data names during a Batch run, with the DT commands in INSPIN, and capturing the responses in INSPLOG. All is well, until I attempt to continue a command onto a second line. Since it's a COBOL program that's running, I start the command in 8, and attempt to continue the statement onto the next line by using a hyphen '-' in column 7 of the continuing line. DT's response is an objection to the second line. Does anyone have experience continuing commands onto another line in the input? Thanks Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: IBM Debug Tool in pure batch
According to: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/eqa9ug00/5.1.4 It looks like you are doing this correctly. Assuming you are current on maintenance, I would report this to the IBM support center (and reference the documentation above). Michael Bradley mjm...@yahoo.com wrote in message news:809234.24313...@web50610.mail.re2.yahoo.com... I'm trying to use the IBM Debug Tool to list some data names during a Batch run, with the DT commands in INSPIN, and capturing the responses in INSPLOG. All is well, until I attempt to continue a command onto a second line. Since it's a COBOL program that's running, I start the command in 8, and attempt to continue the statement onto the next line by using a hyphen '-' in column 7 of the continuing line. DT's response is an objection to the second line. Does anyone have experience continuing commands onto another line in the input? Thanks Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
Hi Everyone, I ran the Histogram utility on both files: On the first file, the maximum block was a bit over 16k and most were about 2k. On the second file most of the blocks were over 25k. So it seems the Syncsort did some major reblocking which caused the savings in both space and access speed. The first file has 2,630,401 blocks. Average block size 1,340 The second file has 129,629 blocks. Average block size 27,115. That’s a 95% reduction in block count. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Walt Farrell Sent: Thursday, January 01, 2009 3:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Syncsort Oddity On Wed, 31 Dec 2008 19:16:43 +, Ted MacNEIL eamacn...@yahoo.ca wrote: When using VB, some code will write a short block if the space remaining in the current block is less than the DCB LRECL, even though the actual length of the next record is unknown. This results in a lot of short blocks, particularly when the LRECL is large, as in this case. So, SYNCSORT 'repairs' this? Any properly written application should repair it, if I remember RECFM=V processing correctly. The LRECL value in the DCB tells you the maximum logical record length. If, when you go to write a logical record, the current data in the block + DCBLRECL is greater than the DCB block size, the access method will truncate the block. As I remember you're supposed to change DCBLRECL to reflect the actual size of the logical record you're about to write, and then the access method can properly fill the block. If you don't update DCBLRECL then if DCBLRECL is close to the blocksize (as it is in the OP's case) and significantly larger than the real LRECLs in the data set, then you could end up with a significant number of unexpectedly short blocks. Presumably SYNCSORT handles all this properly, and so you get optimal blocking, and take fewer tracks than a data set written with less than optimal blocking. Note that these are very old memories... And I know nothing about SYNCSORT. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
