On Mon, 3 May 2010 13:48:38 +0300, Matan Cohen wrote:
>we are trying to use an ftp client on z/os
>using a job to get datasets larger than 4 GB from a windows server after we
>succesfully send the Datasets to the windows FTP server .
>when trying to get the Datasets back to the Mainframe we get t
I noticed that the munging consists of adding a space after every 10th
character of the subject line. In some cases it may appear to be
irregular rather than every 10th character, but that is only because an
already munged subject line has been re-munged after "Re:" or
something was added to th
On 3 May 2010 11:42:47 -0700, in bit.listserv.ibm-main you wrote:
>On Mon, 3 May 2010 08:58:16 -0700, Ed Gould wrote:
>
>>This might be of interest to those wanting to do floating point arithmetic.
>>Please *NOTE* I do NOT know if this pertains to IBM or not.
>>
>>http://floating-point-gui.de/
>>
On Mon, 3 May 2010 14:01:16 -0700, Bob goolsby wrote:
>Mornin' --
>
>This should be required reading in every Engineering/Physics/Computer
>Sciences class "What Every Computer Scientist Should Know About
>Floating Point". ( http://docs.sun.com/source/806-3568/ncg_goldberg.html )
>
>The question co
A gloating and deriding VM bigot proudly told me in 1977 that your code snippet
would break MVT but not VM. But by then I was working with MVS, so I never
tested it on an MVT sandbox, but I did test it on an MVS sandbox. I let the
job run 100% CPU-bound for a couple of minutes, then canceled i
We are in the process of migrating all of our DASD to Hitachi mod 9's. Our
existing catalogs are spread over many of the old 3390's
that are going. I would like to have all of the catalogs on one volume for
the sake of organization. Any issues with this approach
(performance or otherwise)?
Joh
The CCW architecture allows up to 65535 bytes to be transferred by a single CCW
regardless of the device type. The device and/or control unit involved may
have a smaller limit. The largest number of bytes that can be written into a
user record (with Record number not = 0) with a key length of
Mornin' --
This should be required reading in every Engineering/Physics/Computer
Sciences class "What Every Computer Scientist Should Know About
Floating Point". (
http://docs.sun.com/source/806-3568/ncg_goldberg.html )
The question comes up about once a month on the Perl boards (usually
under th
IBM found my EKM problem. If the the alias (cert label)
is exactly 21 characters it fails.
This is fixed in JAVA SR6. Naturally I'm at SR5.
We have ordered the latest JAVA.
--
Richard
--
For IBM-MAIN subscribe / signoff / archi
On 3 May 2010 11:42:47 -0700, m42tom-ibmm...@yahoo.com (Tom Marchant)
wrote:
>Common decimal numbers such as 0.1 can not be accurately
>represented in binary. If you divide X'1' by X'A', you will get
>X'0.1999'. Or try this with your favorite hexadecimal
>calculator. Divide X'100
Yep, just got this too. IBM says IPL to implement as well.
_
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
On Mon, 3 May 2010 08:58:16 -0700, Ed Gould wrote:
>This might be of interest to those wanting to do floating point arithmetic.
>Please *NOTE* I do NOT know if this pertains to IBM or not.
>
>http://floating-point-gui.de/
>
Common decimal numbers such as 0.1 can not be accurately
represented in
*FYI*
You should of course be getting this directly if subscribed to IBM
Notifications for Red Alerts but in case you did not see this.
https://www14.software.ibm.com/webapp/set2/sas/f/redAlerts/home.html
Abstract: z/OS with PTFs for OA30513 can experience data loss due to
deletion of logstream
There is also a job offering section in zJournal. Good luck find your next
job.
ITschak
On Mon, May 3, 2010 at 7:29 PM, Ron Hawkins
wrote:
> Scott,
>
> Did you have a look at the hardware and software vendor sites? Try
> http://www.hds.com/corporate/careers/job-search/index.html, especially the
>This is not to say that someone, somewhere, is not using RECFM=U for something
>not processed by the Binder or IEBCOPY (with COPYMOD), but I have yet to hear
>of anyone doing that.
>I'm willing to be surprised if
someone actually is doing that.
We were, in COBOL many years ago, but had to chan
I never worked with GTFPARS, and only now vaguely remember it, thanks to your
mentioning it.
After CA bought UCCEL in 1987 and redundanted me [1], I lost all contact with
FastDASD's goings-on. So I don't know about its functional replacement by
Astex which occurred with CA's subsequent acquisi
I think pretty much everyone on this list has a story to be told that would
reveal wounds which are still open to this day. I know what mine is.
Let it go. Let it go. You're in good company. ;-)
Scott T. Harder
Mainframe Services, Inc.
Naples, FL
> For myself, I caused an uneeded re-IPL b
I'm curious how you might be expecting to factor in IDRC compression with
the data stored on the tape? I believe that the BLKCNT represents what is
being stored, not what got sent down the channel.
I've been reviewing our tape usage with FATS and the TMC BLKCNT is the
number of uncompressed b
John Eells wrote:
Paul Gilmartin wrote:
On Mon, 3 May 2010 09:22:22 -0400, John Eells wrote:
If I recall correctly, it's 32760 to accommodate BDWs and RDWs for
variable data. You can find a very long post of mine in the archives
about block sizes on DASD.
I believe the BLKSIZE includes the B
Paul Gilmartin wrote:
On Mon, 3 May 2010 09:22:22 -0400, John Eells wrote:
If I recall correctly, it's 32760 to accommodate BDWs and RDWs for
variable data. You can find a very long post of mine in the archives
about block sizes on DASD.
I believe the BLKSIZE includes the BDW and RDWs; they
Scott,
Did you have a look at the hardware and software vendor sites? Try
http://www.hds.com/corporate/careers/job-search/index.html, especially the
one headed Master Performance Consultant - Mainframe-001192.
Anyone on the list is also invited to check it out. And yes this is a
shameless job adv
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould
> Sent: Monday, May 03, 2010 10:58 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: (may or may not be on topic) Floating point arithmetic
>
> This might be of interest to those wantin
Bill,
Cast your mind back to GTFPARS. This IBM FDP would build seek histograms
using IEHLIST VTOC Listings as input to map the extents of the datasets on
the volume.
CA-ASTEX does some very good IO level analysis. As with FASTDASD, CA-ASTEX
intercepts every IO. I think that this replaced FASTDASD
Paul Gilmartin wrote:
Where's the track capacity formula?
I don't know where it is in the current books; I have it on an old
reference card:
Space = C + K + D
C = 10
K, of course, depends on the key length.
If KL = 0, K=0
Otherwise:
K = 9 + (KL + 6KN +6)/34
Where: KN = (KL + 6
Matan,
Just for the record, I was using QFTP from Jolly Giant Software to move
these datasets. It's a little more MVS friendly than most FTP GUI products.
http://www.jollygiant.com/qftpfiletransfer.html.
The datasets were TRSMAIN tersed files.
Ron
> -Original Message-
> From: Ron Hawk
In the IBM-MAIN archives, inter alia. It's in an IBM book or two somewhere
also, of course. I once tried to use the formula for a 3390 to compute the
effective track size of a given blocksize of X, whatever X was for me at that
moment. I gave up on the formula and instead wrote a simple progr
This might be of interest to those wanting to do floating point arithmetic.
Please *NOTE* I do NOT know if this pertains to IBM or not.
http://floating-point-gui.de/
Ed
--
For IBM-MAIN subscribe / signoff / archive access inst
And you can also write one record per track that is as long as the whole track
(ca. 56K bytes) if you use EXCP, XDAP (these first two can run unauthorized),
EXCPVR, or STARTIO (these last two must run authorized). But then the
externally visible metadata - BLKSIZE, LRECL, etc. - may not be auto
McKown, John wrote:
>I'm an idiot.
You are not allowed to feel bad. ;-D
>There were some old AbendAid modules in the linklist above the new libraries.
I don't know why they were there. I deleted them, F LLa,REFRESH, and all
appears to be well.
Ouch, but common. Wrong Linklist and LPA conc
I know this is most likely a no-no, but I am going to go for it:
I am seeking anything from Computer Operator to System Administrator to
program product support; with a preference of something in System
Automation, in a large IBM mainframe installation running z/OS. I will
consider relocating *an
Yup... Have to admit: It is not a very good system that puts the onus on
the customer to massage and alter the data in a problem record, such that it
meets the limited capabilities of the receiving system.
Reporting a problem shouldn't be a problem in and of itself. In a perfect
world, it shoul
GTF traces the seek address (CCHR, et al.) stored in the IOSB but the
post-processing to determine which of the data sets on the volume has each
given traced CCHR within its allocated extents is non-trivial, and I don't know
of anyone who has written such code, unless I did it and have forgotten
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
>
> I'm an idiot. As if the regulars didn't know that. There were some old
AbendAid modules in the
> linklist above the new libraries. I don't know why they were there. I
deleted them, F LLa,REFRESH, and
>
On Mon, 3 May 2010 09:22:22 -0400, John Eells wrote:
>
>If I recall correctly, it's 32760 to accommodate BDWs and RDWs for
>variable data. You can find a very long post of mine in the archives
>about block sizes on DASD.
>
I believe the BLKSIZE includes the BDW and RDWs; they aren't additional.
>
Is the 553 coming from the Windows FTP client? It might be assuming that the
target MVS disk is FAT32 (hence the 4GB limit). If you haven't already
tried it, is there any way you can try to retrieve the file using the MVS
FTP client and a Windows FTP server? [You want to use the same
client/s
I'm an idiot. As if the regulars didn't know that. There were some old AbendAid
modules in the linklist above the new libraries. I don't know why they were
there. I deleted them, F LLa,REFRESH, and all appears to be well.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
Hea
I just installed this on my z/OS 1.10 sandbox system. When I force an S0C3
abend, I get:
AB63-INSUFFICIENT STACK SPACE REMAINING FOR #XAAHEAD TO CONTINUE
AB5A8- ABEND-AID ESPIE EXIT WAS INVOKED
AB5A8- S0C1 ABEND AT 0002D6 IN TMLINK , IL=2, LEVEL=04/06/2009, 14.04, MXA,
PTGABAS.
AB5C3- PSW = 078
timothy.sipp...@us.ibm.com (Timothy Sipples) writes:
> Back when the Web was entirely new and barely developed at CERN, the IBM
> mainframe was the second type of machine in the world to offer a Web user
> interface -- and the first machine anywhere outside Switzerland. Stanford
> University did th
32760 is correct for access method services: you need to leave room for the
BDW which gets added by access method for RECFM=B. Access method services
treats the BLKSIZE as a signed value so values over 32767 are negative, not
positive.
The hardware and EXCP supports larger. I have used 65535
Nope. We have other means to make that determination. The unnamed company
in Nevada provides a nice report.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Saturday, May 01, 2010 7:05 PM
To: IBM-MAIN@bama.ua.edu
On 05/02/2010 08:26 PM, Scott Barry wrote:
> On Sun, 2 May 2010 08:46:49 -0400, Lizette Koehler
> wrote:
>
>> I have a project to review all the virtual tapes in the VTS and see which
>> tape datasets could go on dasd.
>>
>> I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how man
R.S. wrote:
W dniu 2010-05-02 15:04, Ted MacNEIL pisze:
Remember that the maximum blksize on dasd is 27998 ...
No. It's not.
It's 32765.
IBM says it's 32760.
BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset
parameters.
Right.
If I recall correctly, it's 32760 to ac
Lizette Koehler wrote:
I have a project to review all the virtual tapes in the VTS and see which
tape datasets could go on dasd.
I am using CA1 to get the LRECL, BLKSIZE and BLKCNT to determine how many
bytes are on the tape. Then dividing that by the number of bytes per track
to get a rough es
2**0 = 1
>32760 = 4096 x 8
4096 * 8 = 32768
No power of 2 ends in a ZERO (or an odd number).
Whatever the real number is, it's greater than 27998.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email
Add a step to each migration to compress the appropriate target
datasets. That way the "user" will never need to compress.
HTH,
> >Hi,
> >We using RACF on a z/os 1.10.
> >I trying to find a way to permit a user to run a compress job on a
data
> >sets while is access on the data set is READ.
> >a
Jan
Having checked
"IKJEFLN2 - TSO Reconnect Exit for the TN3270 Environment"
http://gsf-soft.com/Products/IKJEFLN2.shtml
it appears that this implementation of IKJEFLN2 performs the same function as
is provided "officially" using the "logonhere" support in z/OS V1R11.
I described this in my
>>BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset
parameters.
>Sometimes?
>When is it not?
Besides having to be a multiple of LRECL for FB files, another situation where
half-track blocking is bad is for a PDS with many members sized at just over a
half track. In this ca
So, if I understand your requirements, it looks like you are creating a
tapeless backup solution to your servers from the Mainframe DFDSS dumps.
The amount of data will be between 2-27GB with 700GB total possible weekly.
How are you creating your DFDSS dumps? Do you use BLKSIZE=32760 on the
out
Is this a very old Windows "Server", or a workstation operating as a "Server",
do you possibly have an older piece of software running the FTP server on the
Windows box? You will get this on any system running FAT32 (or 16) as a
limitation of the File System. Many pieces of software from when t
I see. Do you feel better now? So it's not ok to offend internationally but
it's
ok to offend me? Just want to be clear on the rules here. :)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list
For the past week I have been struggling with a performance problem in our
automation NetView. The NetView behaviour changed when OA29000 allowed
all messages to be considered action messages. Action messages are retained
on internal Netview queues until a DOM is received.
-
Now, we do NOT use A
Thanks Don and Dave!
I must have missed that point in the 1.12 announcement letter.
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Don Imbriale
Sent: Saturday, May 01, 2010 12:09 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SDSF and MQ
On Mon, 3 May 2010 13:48:38 +0300, Matan Cohen
wrote:
>assuming this will work we will want to send on a weekly base an estimate of
>700GB in Datasets between 2-27GB from the z/os to an windows server .
>the data sets which was send should be ready to send back in case of a
>disaster.
Could Sh
On Mon, May 3, 2010 at 11:48 AM, Matan Cohen wrote:
>
> forget about the xmit problem.
> we are trying to use an ftp client on z/os
> using a job to get datasets larger than 4 GB from a windows server after we
> succesfully send the Datasets to the windows FTP server .
> when trying to get the Dat
On Fri, 30 Apr 2010 10:29:02 -0400, zMan wrote:
>
>Is there a better way? On z/VM I'd do a LOGON HERE. Is there some way to
>make TSO "notice" that I'm not there?
>
IKJEFLN2
You can find a version of that in file 183 of the CBT tape. (Thanks again,
Gilbert Saint-flour! This one save my ..s num
>From IBM:
2 May 2010
This is to advise customers that queries using eSupport Knowledge Base
in Service Information Search (SIS) is not working due to technical
problem.
Please go to www.ibm.com/support (http://ww
forget about the xmit problem.
we are trying to use an ftp client on z/os
using a job to get datasets larger than 4 GB from a windows server after we
succesfully send the Datasets to the windows FTP server .
when trying to get the Datasets back to the Mainframe we get the follow
message :
553 Canno
W dniu 2010-05-03 00:35, Rick Fochtman pisze:
---
W dniu 2010-05-02 15:04, Ted MacNEIL pisze:
Remember that the maximum blksize on dasd is 27998 ...
No. It's not.
It's 32765.
IBM says it's 32760.
BTW: 27998 is *sometimes* opti
Thompson, Steve wrote:
>I have been watching subject lines get munged for a while. And so I thought
I'd try to track it down.
Thanks for spotting this.
>In this case it appears to get started when John Gilmore replied to a posting.
>The above subject started out as:
>Calculate Tape Bytes to Trac
>> [me]... Will have to think about it a bit more.
>I think the explanation can be found in the "C/C++ Programming
>Guide", in the chapter about "Using ASA text files" (Chapter 7
>in the recent editions).
Thanks a lot, Bill, for the nice summary!
--
Peter Hunkeler
Credit Suisse
60 matches
Mail list logo
