Re: Question on SPKA and Control Register 3

> I presume the target of Ed's STOSM is in the PSW he's fixing to load. So, > after changing the code to use the STNSM, he'd need to add an OI > PSWMASK,X'03' before the LPSW, as it really sounds like he doesn't want to > run disabled after that. > > Right? Not right. STNSM is Store *Then*

Re: AW: Re: AW: Re: 32760 vs. 32768

On z/VSE, LIOCS limits are 32768. PIOCS limits are 65536 (which we use on tape, a lot). Off hand, I don't know if PIOCS supports 64K on DASD or not. Tony Thigpen Peter Hunkeler wrote on 12/16/2016 11:55 AM: >> Does DOS really support 32768? not 32767? Not sure why I typed DOS. I meant

Re: Question on SPKA and Control Register 3

I presume the target of Ed's STOSM is in the PSW he's fixing to load. So, after changing the code to use the STNSM, he'd need to add an OI PSWMASK,X'03' before the LPSW, as it really sounds like he doesn't want to run disabled after that. Right? On Fri, Dec 16, 2016 at 9:27 PM, Jim Mulder

Re: Question on SPKA and Control Register 3

> > And that means that PSW and your code need to be in fixed or DREF storage. > > Not arguing at all, just trying to educate myself ... why? I don't see > anything in PoOp about STNSM needing fixed storage. PoOp doesn't know anything fixed storage. And it isn't the STNSM that needs the

Re: How to cut and paste shorter URL's

Lose the trailing question mark, too, if you're going to trim the query string. On Fri, Dec 16, 2016 at 11:52 AM, John Mattson wrote: > In general (yes, I know about that) everything which follows the question > mark "?" in a URL is additional baggage. For example >

Re: Question on SPKA and Control Register 3

> And that means that PSW and your code need to be in fixed or DREF storage. Not arguing at all, just trying to educate myself ... why? I don't see anything in PoOp about STNSM needing fixed storage. Charles -Original Message- From: IBM Mainframe Discussion List

Re: P370-L [was: p370 & p390]

I do..Can we talk off forum?Regards Sent from Yahoo Mail on Android On Fri, Dec 16, 2016 at 20:06, Norman Hollander on Desertwiz wrote: Do you have the IBM Redbook for P370/P390? -Original Message- From: IBM Mainframe Discussion List

Re: Question on SPKA and Control Register 3

> >> After it showed up on a customer's STROBE report, we switched over to > >> using LPSW instead... > > If you're unlucky enough to hit the edge case, you will lose the PER bit > > by doing so. > > Actually, that's a good point. If we get interrupted after the STOSM and > before the LPSW,

Re: AW: Re: 32760 vs. 32768

On Fri, 16 Dec 2016 16:12:14 -0600, Mike Schwab wrote: >If you are coming from VBS on z/VSE you should keep the data set in >VBS on z/OS. With a multipart record you can essentially have an >unlimited length record. > And a lot of z/OS software will refuse to deal with it. But VBS should have

AW: Re: No BDW for RECFM=V was Re: 32767?

> The z/OS 2.2 manual has the same diagram, but KC search didn't find it. The diagram is a bit confusing because where it shows the unblocked records, Record B is not shown with the BDW, but Record A and Record C are. This is an erroneous remake of the diagram as it existed in old manuals,

Re: AW: Re: 32760 vs. 32768

If you are coming from VBS on z/VSE you should keep the data set in VBS on z/OS. With a multipart record you can essentially have an unlimited length record. On Fri, Dec 16, 2016 at 10:55 AM, Peter Hunkeler wrote: > > >> Does DOS really support 32768? not 32767? > > > Not sure why

Re: TSO LINE COMMAND - EDIT MODE

> On Dec 16, 2016, at 2:35 PM, Gibney, Dave wrote: > > Often, or at least sometimes for me, there will be numbers in the number > columns, but they aren't still valid as ISPF number mode. And the UNNUM > command returns a not in number mode message. Here is what I did. RENUM

Re: P370-L [was: p370 & p390]

Do you have the IBM Redbook for P370/P390? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Neil Duffee Sent: Friday, December 16, 2016 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: P370-L [was: p370 & p390] I have the following

Re: P370-L [was: p370 & p390]

I have the following snippet from the listserv that you could use... To: L-Soft list server at Princeton University (1.8e) Subject: Re: SUBSCRIBE p370-l SUBSCRIBE p370-l -Original Message- From: W Mainframe [mailto:mainfra...@yahoo.com] Sent:

Re: No BDW for RECFM=V was Re: 32767?

On Fri, 16 Dec 2016 13:03:04 -0600, Tom Marchant wrote: >On Fri, 16 Dec 2016 10:16:12 -0400, Clark Morris wrote: > >>For RECFM=V LRECL includes the 4 byte RDW and there is no BDW. I just >>checked Knowledge center. >

Re: Question on SPKA and Control Register 3

On 12/15/2016 4:21 PM, Peter Relson wrote: After it showed up on a customer's STROBE report, we switched over to using LPSW instead... If you're unlucky enough to hit the edge case, you will lose the PER bit by doing so. Actually, that's a good point. If we get interrupted after the STOSM

Re: how to: convince programmer something else is better.

Assuming your site "bought all the bits", it *will* look like a Mainframe. See here, http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.studee60ux%2FHCOMCMCBLKS005.html, for accessing "MVS Control Blocks" for JOB and step information. There's even

Re: how to: convince programmer something else is better.

On Fri, Dec 16, 2016 at 2:30 PM, Bill Woodger wrote: > Micro Focus COBOL can be configured to "work like Mainframe COBOL": it can > be used for "off Mainframe" development for a Mainframe target (requiring > recompile) and for "migration from Mainframe with as few changes

Re: TSO LINE COMMAND - EDIT MODE

Often, or at least sometimes for me, there will be numbers in the number columns, but they aren't still valid as ISPF number mode. And the UNNUM command returns a not in number mode message. I find that NUM ON STD (or COB if appropriate) Followed by UNNUM Clears the area > -Original

Re: how to: convince programmer something else is better.

Micro Focus COBOL can be configured to "work like Mainframe COBOL": it can be used for "off Mainframe" development for a Mainframe target (requiring recompile) and for "migration from Mainframe with as few changes as possible". I'm not saying it is perfect, but with V3 it should be very good.

Re: No BDW for RECFM=V was Re: 32767?

On Fri, 16 Dec 2016 10:16:12 -0400, Clark Morris wrote: >For RECFM=V LRECL includes the 4 byte RDW and there is no BDW. I just >checked Knowledge center. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_1.13.0/com.ibm.zos.r13.idad400/d4356.htm The z/OS 2.2 manual has the same diagram, but

Re: how to: convince programmer something else is better.

On Fri, Dec 16, 2016 at 12:17 PM, Bill Woodger wrote: > If I remember correctly, John, you are on an Enterprise COBOL V3 compiler, > which has a 16MB size-limit for tables (V4 upped that to 134MB, V5+ even > more). > > Just to check, the compression is only for DASD

Re: how to: convince programmer something else is better.

If I remember correctly, John, you are on an Enterprise COBOL V3 compiler, which has a 16MB size-limit for tables (V4 upped that to 134MB, V5+ even more). Just to check, the compression is only for DASD saving? There's a slight possibility it also used for getting around that limit. Assuming

Re: [EXTERNAL] Re: TSO LINE COMMAND - EDIT MODE

If those columns are edit sequence numbers then you can't change those with the change commands. Use UNNUM to remove them. -- Lionel B. Dyck Mainframe Systems Programmer - TRA Enterprise Operations (Station 200)

Re: TSO LINE COMMAND - EDIT MODE

Try UNNUM ? Ed > On Dec 16, 2016, at 9:15 AM, willie bunter > <001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: > > Good Day To All, > > Is there a way of filling columns 80 95 with blanks? I have sequence > commands (please see below for an example) which I would like to remove. > >

Re: TSO LINE COMMAND - EDIT MODE

Sri, I checked. The column positions were 80-95. Not sure why it wouldn't work. anyway, what is good is that with the help I received all is well. Thanks for taking the time to help me out. On Fri, 12/16/16, Sri h Kolusu

Re: how to: convince programmer something else is better.

On Fri, Dec 16, 2016 at 11:17 AM, John Mattson wrote: > It may be uncharitable of me, but perhaps you are talking about how to the > job well, and the programmer is talking about his/her job security. Create > something hard enough to maintain, and your job security is

Re: how to: convince programmer something else is better.

It may be uncharitable of me, but perhaps you are talking about how to the job well, and the programmer is talking about his/her job security. Create something hard enough to maintain, and your job security is pretty much assured. Reference the "programming standards" article in the recent

AW: No BDW for RECFM=V was Re: 32767?

>For RECFM=V LRECL includes the 4 byte RDW and there is no BDW. I just checked Knowledge center. I might missread your statement, but if you meant to say that a block in a RECFM=V data set does *not have a BDW, only the record has its RDW, then this is *not* true. Every RECFM=V block

AW: Re: AW: Re: 32760 vs. 32768

>> Does DOS really support 32768? not 32767? Not sure why I typed DOS. I meant z/VSE. Sorry >From a vtoc (two different files) where I was trying to move some data from VSE to z/OS: > >RECFM BLKSIZE Created Expires >DSORG LRECL .DDD .DDD >SAM VBS 56660 32768 2016.339

How to cut and paste shorter URL's

In general (yes, I know about that) everything which follows the question mark "?" in a URL is additional baggage. For example http://www.computerworld.com/article/3150217/application- development/but-at-least-he-enforced-programming-standards.html?

AW: Re: 32767?

>It is NOT true that RECFM=V on z/OS has ONLY an RDW. I did not claim that. (Did you want to reply to a different post than mine?) >RECFM=V on z/OS has BOTH the BDW and the RDW. Just what I said, and the BDW is 4 bytes. -- Peter Hunkeler -Original Message- From: IBM Mainframe

Re: 32767?

On Fri, 16 Dec 2016 07:34:46 -0600, Tom Marchant wrote: > >The maximum BLKSIZE for DASD is 32760. > In fact: z/OS 2.2.0 z/OS DFSMS z/OS DFSMS Using Data Sets Non-VSAM Access to Data Sets and UNIX Files Specifying and Initializing Data Control Blocks Selecting Data Set

Re: 32767?

On Fri, 16 Dec 2016 06:01:56 -0600, Bill Woodger wrote: > >The RC for the message goes up steps of four, and is already busted. Other RC >values have multiple items. Some are not even inclusive, and probably can't be. > >I think it is unrealistic to expect a separate RC for each possible

Re: TSO LINE COMMAND - EDIT MODE

1000% agree, even extended help (after PF1) give the user no clue as to what was not found. Carmen - Original Message - From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, December 16, 2016 10:19:15 AM Subject: Re: TSO

Re: TSO LINE COMMAND - EDIT MODE

On Fri, 16 Dec 2016 08:55:18 -0700, Sri h Kolusu wrote: > >You need to use '^' instead of '�' > >C P'^' '' 80 95 ALL > >^ is the non blank character when your encoding scheme is 1047 on the >mainframe > I hate EBCDIC! >> From: willie bunter >> >> I tried out your suggestion but it didn't

Re: [EXTERNAL] Re: TSO LINE COMMAND - EDIT MODE

This should work: C P'=' ' ' 85 90 all The P'=' tells ISPF Edit any character -- Lionel B. Dyck Mainframe Systems Programmer - TRA Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, IT

Re: TSO LINE COMMAND - EDIT MODE

Wow ! OK great, that was my only other guess was your boundary were set to 70 or less. glad it worked OK for you Have a Merry Christmas as well ! Carmen - Original Message - From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent:

Re: TSO LINE COMMAND - EDIT MODE

Willie, Are the column positions 80 thru 95 the correct positions of your data? If it worked partially, I am guessing that your column positions are different from what you described. Make sure you have the right column positions. Thanks, Kolusu IBM Mainframe Discussion List

Re: TSO LINE COMMAND - EDIT MODE

Carmen, The command C P'^' ' ' 73 80 ALL did the trick. I do not know why it wouldn't work before. I checked to see if I BNDS set but it wasn't A massive thank you to you and the all who offered suggestions. For those who are celebrating Christmas please permit me to wish you all a very

Re: TSO LINE COMMAND - EDIT MODE

Then maybe the easier way is to set boundaries from 80 to 95 using the BNDS line command then X ALL and shift )200 everything over 200 chars then reset your boundary back ? Carmen - Original Message - From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> To:

Re: TSO LINE COMMAND - EDIT MODE

So did you look at the Picture String function in ISPF. When you specify 00 in the P parm p'00' it is ONLY looking for the 00 not anything else. C P'^^' ' ' all 95 96 (the ^ is the Not Sign, keyboard did not translate that well) This changes any NON BLANK character to blanks. You can

Re: TSO LINE COMMAND - EDIT MODE

Kolusu, I tried your suggestion but the command worked partially. It removed an ending zero before the command: 0001 after the command 0001000 On Fri, 12/16/16, Sri h Kolusu wrote: Subject: Re: TSO LINE COMMAND - EDIT

Re: TSO LINE COMMAND - EDIT MODE

Sorry. I tried it out (copy pasted your command) but I get the message No CHARS '^' found On Fri, 12/16/16, Carmen Vitullo wrote: Subject: Re: TSO LINE COMMAND - EDIT MODE To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday,

Re: TSO LINE COMMAND - EDIT MODE

on my terminal the carrot p'^' translates to NE sign, '¬' sure you don't have ant BNDS set that will now allow you to see or change past col80 ? =BNDS> > - Original Message - From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent:

Re: 32767?

It is NOT true that RECFM=V on z/OS has ONLY an RDW. RECFM=V on z/OS has BOTH the BDW and the RDW. RECFM=V on DOS has only a 4-byte RDW. NOTE: THE INFILE VFILE IS is RECFM=V,LRECL=32756,BLKSIZE=32760 When read with RECFM=U you can see both the BDW and the RDW. RULE:

Re: TSO LINE COMMAND - EDIT MODE

Classification: Public This might depend on your code page settings. For me, using IBM-1047, it's: C P'^' ' ' 80 95 ALL Where the '^' is the shift-6 character (on my UK keyboard!). To find out what character you're expected to use, in EDIT, issue: HELP 14 2 CHANGE 1 3 This should take you

Re: TSO LINE COMMAND - EDIT MODE

Carmen, I tried C P'¬' ' ' 80 95 ALL as well as C '¬' NX " " ALL but I get : No CHARS '¬' found On Fri, 12/16/16, Carmen Vitullo wrote: Subject: Re: TSO LINE COMMAND - EDIT MODE To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday,

Re: TSO LINE COMMAND - EDIT MODE

Willie, You need to use '^' instead of '¬' C P'^' '' 80 95 ALL ^ is the non blank character when your encoding scheme is 1047 on the mainframe Thanks, Kolusu IBM Mainframe Discussion List wrote on 12/16/2016 08:45:22 AM: > From: willie bunter

Re: TSO LINE COMMAND - EDIT MODE

I believe Lionel's example is correct : c p'=' ' ' 85 90 all carmen - Original Message - From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, December 16, 2016 9:51:58 AM Subject: Re: TSO LINE COMMAND - EDIT MODE

Re: TSO LINE COMMAND - EDIT MODE

strange, did you just C ¬' ' ' 80 95 ALL or the correct format Bill provided C P'¬' ' ' 80 95 ALL - you need the 'P" picture clause Carmen - Original Message - From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, December

Re: [EXTERNAL] Re: TSO LINE COMMAND - EDIT MODE

I tried it but nothing was changed. Thanks for the suggestion. On Fri, 12/16/16, Dyck, Lionel B. (TRA) wrote: Subject: Re: [EXTERNAL] Re: TSO LINE COMMAND - EDIT MODE To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday, December 16,

Re: [EXTERNAL] Re: TSO LINE COMMAND - EDIT MODE

Try something like this then: c p'=' ' ' 85 90 all -- Lionel B. Dyck Mainframe Systems Programmer - TRA Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, IT Operations and Services Office:

Re: TSO LINE COMMAND - EDIT MODE

Carmen, I gave it a shot but I get message :No CHARS '¬' found On Fri, 12/16/16, Carmen Vitullo wrote: Subject: Re: TSO LINE COMMAND - EDIT MODE To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday, December 16, 2016, 10:32 AM you

Re: TSO LINE COMMAND - EDIT MODE

In ISPF I use C P'=' ' ' n n ALL Jay Campbell MSSD – IZSSB – IOSSS -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Carmen Vitullo Sent: Friday, December 16, 2016 10:48 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: TSO LINE

Re: TSO LINE COMMAND - EDIT MODE

Bobby, I tried your command but it removed only 1 zero from the extreme end i.e. before: 0001 after: 0001000 On Fri, 12/16/16, Herring, Bobby wrote: Subject: Re: TSO LINE COMMAND - EDIT MODE To:

Re: TSO LINE COMMAND - EDIT MODE

Bill, I tried out your suggestion but it didn't work. I get the message No CHARS '¬' found On Fri, 12/16/16, George, William@FTB wrote: Subject: Re: TSO LINE COMMAND - EDIT MODE To: IBM-MAIN@LISTSERV.UA.EDU Received:

Re: TSO LINE COMMAND - EDIT MODE

I believe the command you need is: C P'¬' ' ' 80 95 ALL The picture P'¬' finds all NON blank characters. Bill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Friday, December 16, 2016 7:15 AM To:

Re: IBM Automatic Binary Optimizer

Note that in the future, ABO will be able to deal with V5/V6 (and onwards) executables, and those will for sure need PDSE. There are some PDSE requirements for PDSE, not for executables, they are documented and have been mentioned here in recent topics on ABO.

Re: TSO LINE COMMAND - EDIT MODE

Not sure where I got this a while ago, so I apologize to the original author in advance. I call it BLANKIT. Bob /* REXX */ Signal On NoValue Parse source opsys . exec_name . If opsys =

Re: TSO LINE COMMAND - EDIT MODE

I use this command to do that: C P'^' '' 80 95 ALLThat carat character tells it to change non-blank characters to null. Bobby Herring Texas Farm Bureau Insurance -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent:

Re: TSO LINE COMMAND - EDIT MODE

you can rerun that command for any other char or use the command to change any non blank char in those fields I don't have a system right now to test but I believe C P'¬' NX " " ALL will change any NO BLANK CHAR to " " BLANK Carmen - Original Message - From: "willie bunter"

Re: TSO LINE COMMAND - EDIT MODE

How about ))15 followed by ((15 on the last line? With complementary )) and (( on the last line. Sent from my iPhone > On Dec 16, 2016, at 10:24, willie bunter > <001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: > > John, > > I tried out your suggestion and it pariallly worked..

Re: IBM Automatic Binary Optimizer

The PDSE Requirement is for Enterprise COBOL Compiler at V5 and above. ABO works with Cobol load modules below Enterprise Cobol V5. I do not think you use ABO for an Enterprise V5 and above Cobol Program. So I would say no Lizette > -Original Message- > From: IBM Mainframe

Re: No BDW for RECFM=V was Re: 32767?

On Fri, 16 Dec 2016 10:16:12 -0400, Clark Morris wrote: > >For RECFM=V LRECL includes the 4 byte RDW and there is no BDW. I just >checked Knowledge center. > Cite, please (more precisely than "KC"). I find: z/OS 2.2.0 z/OS DFSMS z/OS DFSMS Using Data Sets Non-VSAM Access to Data Sets and UNIX

Re: TSO LINE COMMAND - EDIT MODE

John, I tried out your suggestion and it pariallly worked.. The 00 were removed however the non-00 were left. 63 64 02 ** 65 Thanks for your help. On Fri, 12/16/16, John McKown wrote:

Re: TSO LINE COMMAND - EDIT MODE

Here's a REXX that I wrote to do the same thing as the Roscoe FILL command. PARMS are the start and end columns. /*REXX--*/ /* */ /* FUNCTION:

Re: TSO LINE COMMAND - EDIT MODE

You could create a smaller dataset, copy the current one to the new one which truncates the end of the line, then copy it back into you original dataset. You could create a EDIT MACRO to do the change. You could create a batch REXX to do the change Create a sort process to edit the file. It

Re: AW: Re: 32760 vs. 32768

> Does DOS really support 32768? not 32767? From a vtoc (two different files) where I was trying to move some data from VSE to z/OS: RECFM BLKSIZE Created Expires DSORG LRECL .DDD .DDD SAM VBS 56660 32768 2016.339 2016.339 SAM VBS 56660 32768 2016.339 2016.339

Re: TSO LINE COMMAND - EDIT MODE

On Fri, Dec 16, 2016 at 9:15 AM, willie bunter < 001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: > Good Day To All, > > Is there a way of filling columns 80 95 with blanks? I have sequence > commands (please see below for an example) which I would like to remove. > > 00550003 ** >

TSO LINE COMMAND - EDIT MODE

Good Day To All, Is there a way of filling columns 80 95 with blanks? I have sequence commands (please see below for an example) which I would like to remove. 00550003 ** 0056 00570001 * 00580003 ** 0059 0061 * 00610003 ** 0062 00630001 *

AW: Re: 32760 vs. 32768

>Recently, I had a file transfer issue between z/VSE and z/OS because VSE support block lengths of 32768 (true 32k) while z/OS only supports 32760 (32k-8). Does DOS really support 32768? not 32767? 32KiB -7 that is. The maximum positive number is 32767 not 23768. -- Peter Hunkeler

AW: Re: 32767?

>The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a >RECFM=VB dataset. When it comes to BLKSIZE versus LRECL, there is *no* difference between RECFM=V and RECFM=VB. And even the print control character variants with the additional A or M in th RECFM do not make it any

No BDW for RECFM=V was Re: 32767?

[Default] On 16 Dec 2016 05:34:12 -0800, in bit.listserv.ibm-main 000a2a8c2020-dmarc-requ...@listserv.ua.edu (Tom Marchant) wrote: >On Fri, 16 Dec 2016 07:22:59 +, Vernooij, Kees wrote: > >>The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a >>RECFM=VB dataset. For

Re: 32760 vs. 32768

No, it was possible to implement this downward compatible, because there was unused space in the 32-bit registers that could be used for 31-bit, while 24-bit remained supported and for 64 bit, registers were expanded while supporting the old registers. This was possible because the

Re: 32760 vs. 32768

IMHO "more impossible" was to move from 24 to 31 bit or to 64 bit addressing. Not to mention 1TB volumes ;-) Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2016-12-16 o 14:50, Vernooij, Kees (ITOPT1) - KLM pisze: I think that the effort to track down all the halfwords and convert them

Re: 32760 vs. 32768

I think that the effort to track down all the halfwords and convert them plus the supporting software, was considered impossible. Applying disk efficiency with half-track blocksizes was much easier. Kees. -Original Message- From: IBM Mainframe Discussion List

Re: 32760 vs. 32768

W dniu 2016-12-16 o 14:37, Tom Marchant pisze: On Fri, 16 Dec 2016 07:41:59 -0500, Tony Thigpen wrote: Recently, I had a file transfer issue between z/VSE and z/OS because VSE support block lengths of 32768 (true 32k) while z/OS only supports 32760 (32k-8). In MVS, LRECL and BLKSIZE are

Re: 32760 vs. 32768

On Fri, 16 Dec 2016 07:41:59 -0500, Tony Thigpen wrote: >Recently, I had a file transfer issue between z/VSE and z/OS because VSE >support block lengths of 32768 (true 32k) while z/OS only supports 32760 >(32k-8). In MVS, LRECL and BLKSIZE are stored as signed halfword values. -- Tom Marchant

Re: 32767?

On Fri, 16 Dec 2016 07:22:59 +, Vernooij, Kees wrote: >The BLKSIZE must be 4 more than LRECL for a RECFM=V dataset and 8 for a >RECFM=VB dataset. For a RECFM=V data set, BLKSIZE must indeed be 4 greater than LRECL. That is to allow room for the Block Data Word. The Record Data Word is

Re: IBM Automatic Binary Optimizer

Summary of Changes indicates no change related to PDSE. Executable ABO output do not require, and have not previously required, PDSE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

IBM Automatic Binary Optimizer

With ABO v1.2, is there still a requirement for PDS/E? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: 32760 vs. 32768

Recently, I had a file transfer issue between z/VSE and z/OS because VSE support block lengths of 32768 (true 32k) while z/OS only supports 32760 (32k-8). Does anybody know (historically) why z/OS does not support a true 32K block? z/VSE has supported it since "way back" in the DOS days.

Re: z/OS 2.2 SMF record corrupted

Pfewww. Going to 2.2 on production on Sunday, luckily still with MAN datasets. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Salva Carrasco Sent: 16 December, 2016 13:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.2 SMF

z/OS 2.2 SMF record corrupted

Hi all. SMF record corrupted at offset x16, high order bit zeroed, in (almost) types: 4, 14, 15, 20, 61, 62, 65, 64, 66, 80, 208, 241. Sample (E7 become 67 at offset 19): +1+2+ & ¢ BCARXPRODPL 1500B10131CCCD2000EDDDCDD E0060B165F231980507796473

Re: 32767?

32760 is the maximum blocksize. You have an LRECL of 32760, which is not at least four bytes less than the maximum blocksize. The RC for the message goes up steps of four, and is already busted. Other RC values have multiple items. Some are not even inclusive, and probably can't be. I think it

Re: 32767?

I'm still before first coffee, but I would rephrase it: The BLKSIZE must be 4 more than *usable record length* for a RECFM=V dataset and 8 for a RECFM=VB dataset. LRECL is (max) record lentgh *including* RDW, not just user data. Picture: RDW-user_data...