I have to remember to look at the IBM-MAIN list rather than the archives.
Thanks, everybody, for your help. I'm glad to have another means of tracing for
the (shudder) next time around.
Steve
Steve Pryor
DTS Software, LLC
st...@dtssoftware.com
Well, after considerable struggle involving setting up a completely new FTP
server and experimenting with virtually every possible setting on both sides,
it seems that this can occur if the TLS level used by the z/OS client isn't
supported by the Linux ProFTPD server. Some settings rejiggering
Can REQUEST=FUNCTIONBEGINs be nested? I.e. follow a
REQUEST=FUNCTIONBEGIN with another REQUEST=FUNCTIONBEGIN without an
intervening REQUEST=FUNCTIONEND to collect data on sub-functions? Can I
use the PRODQUAL= to delineate the sub-function?
j
--
John Szura
Lead Mainframe Product Developer
Tony, I assume when you say "mini z/OS V2R1 system" that includes SDSF. If
yes, allocate a sysout type dataset. Mine is userid.print.out (org=po,
recfm-fb, lrecl 133, blksize-13300 (or 26600, or ...)). Select your job in
JES, either an individual output segment or the entire job. On the
thanks. I got it down.
Tony Thigpen
Pommier, Rex wrote on 3/2/21 4:08 PM:
SDSF to get it to a flat file then IND$FILE to transfer it? AFAIK, IND$FILE
can't handle spool data directly.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Tony Thigpen
Sent: Tuesday,
SDSF to get it to a flat file then IND$FILE to transfer it? AFAIK, IND$FILE
can't handle spool data directly.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Tony Thigpen
Sent: Tuesday, March 2, 2021 3:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] getting
I have a mini-z/OS 2.1 system that currently has no TCP/IP or other
connection that I could use to transfer reports. I just have TN3270
access via an ICC. I need to get a report out of JES2. Is there a way
using an IND$FILE type transfer to get the report down to the PC?
Tony Thigpen
My recommendation was specifically for z/OS; I don't know how z/VSE handles
multiple READs, and I would expect most CMS I/O to be native CMS, BFS or SFS.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
> In theory, using EXCP, you could read using CCWs with data chaining
> that would read multiple blocks in one I/O operation and concatenate them
> into one data area.
Only if you used Read Multiple CKD; given that SAM-E is bundled into z/OS, I'm
not convinced that you'd get a noticeable
I believe that the DCB information specified by the program should take
precedent. However, I also believe that a utility should not override the block
size of an existing dataset. When dataset has an existing blocksize and the DD
or DYNALLOC has a different blocksize, then I believe that OPEN
> Where's QPAM that we've needed forever?
In TSS/360. I guess that it's too recent to copy.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin
I would describe changing the block size of an existing dataset to a hard wired
value as "Broken As Designed (BAD)".
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
On Tue, 2 Mar 2021 19:10:49 +0100, Peter Sylvester wrote:
>
>A little example from few days ago. Files are 30 years old.
>
>A pds with blksize 6160 that already had members (longer than a block)
>
It is a dreadful design blunder (which could yet be repaired) that
the OS allows:
o Decreasing the
Hi
A little example from few days ago. Files are 30 years old.
A pds with blksize 6160 that already had members (longer than a block)
1st try:
RECEIVE INDATASET(whatever) OUTDATASET(pds(member)) -> oops really, not possible to allocate
a member. resulting in an abend?
2nd try:
On Tue, 2 Mar 2021 11:30:09 -0600, Walt Farrell wrote:
>
>I'm surprised no one has mentioned it, but for input files, the blocksize is
>determined by the application that wrote the file. The application that is
>reading has no control over it. ...
>
Except for zFS, for which the access method
On Tue, 2 Mar 2021 16:02:35 +, Seymour J Metz wrote:
>Why is that an enhancement rather than a bug fix? Isn't SDB supposed to be
>active only if BLKSIZE=0? Are you sure that RECEIVE allocated the target with
>a nonzero block size?
>
To what extent do programmers approve the OS's overriding
On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman
wrote:
>I have 100 files concatenated that are normally processed by qsam with a lrecl
>31996 and blksize 32000
>
>Since processing takes a long time I was looking to speed things up by
>specifying a blksize of 32 in the DCBE
>
>After
On Tue, 2 Mar 2021 16:35:46 +, Seymour J Metz wrote:
>For best performance, NCP should match the number of DECBs you allocate and
>you should do a READ on each of them. If real storage is an issue, reduce that
>number appropriately. When you hit EOF (EODAD is entered), stop issuing READ.
>
That’s the way I’m doing it
Thanks
> On Mar 2, 2021, at 11:36 AM, Seymour J Metz wrote:
>
> For best performance, NCP should match the number of DECBs you allocate and
> you should do a READ on each of them. If real storage is an issue, reduce
> that number appropriately. When you hit EOF
For best performance, NCP should match the number of DECBs you allocate and you
should do a READ on each of them. If real storage is an issue, reduce that
number appropriately. When you hit EOF (EODAD is entered), stop issuing READ.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
Why is that an enhancement rather than a bug fix? Isn't SDB supposed to be
active only if BLKSIZE=0? Are you sure that RECEIVE allocated the target with a
nonzero block size?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe
Re: "The format is gsktrace > gskfile.trc > gsk.out "
John is right--it's just gsktrace gskfile.trc > gsk.out
Sorry guys.
Wendell
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
If anyone has had a problem trying to use System Determined Blocksize with TSO
RECEIVE and getting a message IEB1139W like:
IEB1139W THE OUTPUT DATA SET BLOCK SIZE IS BEING REDUCED FROM 32720 TO 27920
BYTES. ANY EXISTING PHYSICAL RECORDS LONGER THAN 27920 BYTES ARE FAT BLOCKS
AND MAY CAUSE
Yes, of course!
9 will be blocked to 3x3.
However for VSAM it is possible to get 9 blk/trk, as well as 4, 12, 10,
8...
Of course it is not the same as SDB for PS file.
--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland
W dniu 02.03.2021 o 15:33, Paul Gilmartin pisze:
On Tue, 2 Mar
On Tue, 2 Mar 2021 15:25:33 +0100, Radoslaw Skorupka wrote:
>try any RECFM=FB and LRECL between 13349 and 18118
>
>Generally it may be 1/3 or other 1/n where n is odd (uneven).
>
It must be either prime or 1.
Has anyone an example for 1/11?
(Always assuming Blocked.)
>As currently unemployed I
try any RECFM=FB and LRECL between 13349 and 18118
Generally it may be 1/3 or other 1/n where n is odd (uneven).
As currently unemployed I have no z/OS at hand (OK, I have one due to
someone's kindness), when you play with large enough LRECLs you will get
SDB at 3 blk/trk, 5 blk/trk, 7 blk/trk
On Tue, 2 Mar 2021 08:24:09 -0500, David Spiegel wrote:
>Hi Radek,
>You said: "... which is usually close to half of the track (sometimes
>third...) ..."
>When is SDB 1/3 Track?
>
As a guess, try RECFM=FB,LRECL=16385,BLKSIZE=0.
In one astonishing extreme case, SDB is 1/7 track.
-- gil
Hi Radek,
You said: "... which is usually close to half of the track (sometimes
third...) ..."
When is SDB 1/3 Track?
Thanks and regards,
David
On 2021-03-02 07:25, Radoslaw Skorupka wrote:
General comment about LBI, large blocks and performance:
1. Blocksize for tapes, especially for real
Thanks I look at the IHADCB DSECT comments
> On Mar 2, 2021, at 2:18 AM, Michael Stein wrote:
>
> On Mon, Mar 01, 2021 at 09:37:57PM -0500, Joseph Reichman wrote:
>> For NCP do you have to have a counter of the number of reads you do
>> till you do a check
>
> Yes, but since you need a
General comment about LBI, large blocks and performance:
1. Blocksize for tapes, especially for real tapes is very important for
performance. LBI is something to legalize previously used large blocks -
I mean blocks larger than officially supported 32760. Even 3490E tapes
supported larger
"PROG 764 Load PS STRUCTURED FIELD error: An invalid slot number was
specified."
https://bit.listserv.vse-l.narkive.com/lAKe0vjB/xprog753-error
Joe
On Tue, Mar 2, 2021 at 6:08 AM Radoslaw Skorupka
wrote:
> W dniu 02.03.2021 o 09:16, Alexander Huemer pisze:
> > Hi
> >
> > I was recently
W dniu 02.03.2021 o 09:16, Alexander Huemer pisze:
Hi
I was recently researching an error condition with IBM Personal
Communications, causing 'PROG 764' to be displayed.
The only result google spit out was a post on the list, from 10 years
ago[1]. The links are all dead now. The post contains
Indeed, thank you!
-Alex
On Tue, Mar 02, 2021 at 08:28:52AM +, Gadi Ben-Avi wrote:
> The online help has descriptions of all of the messages.
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Alexander Huemer
> Sent: Tuesday, March 2, 2021 10:17 AM
> To:
The online help has descriptions of all of the messages.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Alexander Huemer
Sent: Tuesday, March 2, 2021 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Personal Communications error codes
Hi
I was recently researching
Hi
I was recently researching an error condition with IBM Personal
Communications, causing 'PROG 764' to be displayed.
The only result google spit out was a post on the list, from 10 years
ago[1]. The links are all dead now. The post contains some good
information anyways.
Is anybody aware of
35 matches
Mail list logo
