Re: z/OS Unix and VBA files.

[Hunkeler Peter (KIUP 4)]

>> [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

--
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: Munged Subject [Calcul ate Tape B ytes to Tr acksþ]

[Elardus Engelbrecht]

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 Tracksþ
>And with John's first reply it became:
>Calcul ate Tape B ytes to Tr acksþ
>Anyone have any idea what would do this?

Sorry, John Gilmore, please forgive me, but I do not wish you anything bad or 
unfavourable, but I also saw this munging of the 'Subject fields' caused by 
your posts.

 Re: IEBCOP Y losing A PF autho risation i n middle o f JOB - et c## 
 Re: IEBCOP Y losing A PF authori sation in middle of JOB - etc? 
 Re: IEBCOP Y losing A PF authori sation in middle of JOB - etc# 
 Re: IEBCOPY losing APF authorisation in middle of JO B - etc# 
 Re: IEBCOPY losing APF authorisation in middle of JOB - etc 

Above was taken from April 2010 IBM-MAIN List Serv Web page.
Note, I have replaced unreadable characters with '#'.

Also John's answer in this thread :
(copied to NotePad and unreadable characters changed to '#')

Munged Sub ject [Calc ul ate Tap e B ytes t o Tr acks# ]#

Please note that the '# ]#' is changed to '[' on IBM-MAIN List Serv Web page. 
See below as it appears on the Web page:

Munged Sub ject [Calc ul ate Tap e B ytes t o Tr acks[


Anyone willing to help out John?

Groete / Greetings
Elardus Engelbrecht

--
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: Calculate Tape Bytes to Tracks

[R.S.]

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* optimal blksize. It depends on other dataset
parameters.


-
I've seen blocks longer than 32,767 written on 3390 SLEDs using IDAW.
What IBM quotes is the biggest BLKSIZE in JCL, not necessarily the
actual hardware max.


Both sentences can be true. Hardware limit is not the same as BLKSIZE 
limit in the operating system. I was told that VSE can use blocks of 56k 
(whole track). Linux on the same hardware has significantly different 
way of storing data on disk.


BTW: It is possible to create dataset with BLKSIZE=32767, but you cannot 
use BLKSIZE=327676 construct - it would end with JCL error.
BTW2: I said what IBM says. It was intentionally to put the word in 
IBM's mouth, because of the issues above.
BTW3: "maximum blksize on dasd is 32765" is neither what IBM says, nor 
achievable 32767, nor HW limit. 



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
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: recommended way to send large files from Z/os to WIN and backward

[Matan Cohen]

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 Cannot send file larger than 4 gigabytes.
we are trying to understand if the problem is cause from the windows side.
we do use an SMS Data class so the Datasets will be a multivolume.

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.



On Mon, May 3, 2010 at 8:38 AM, Timothy Sipples
wrote:

> What sort of data are in these datasets? A little background on why you're
> proposing to transfer large datasets (files) might be helpful, too.
>
> Also, do you have any sort of requirements for how quickly they need to be
> transmitted (in both directions)? How often? How reliably? Does the network
> link (or, for that matter, the data) need to be secured in some way?
>
> - - - - -
> Timothy Sipples
> Resident Architect (Based in Singapore)
> STG Value Creation and Complex Deals Team
> IBM Growth Markets
> E-Mail: timothy.sipp...@us.ibm.com
>
> --
> 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
>



-- 
best regards,
matan cohen
MF System Administrator.

--
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

SIS broken on IBMLINK

[Jousma, David]

>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://www.ibm.com/support) instead of
eSupport Knowledge Base in SIS till the issue is resolved.

_
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


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: tso session timeout

[Jan MOEYERSONS]

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 numerous times when we were still on 
that Flex box...)

Cheers,

Jantje.

--
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: recommended way to send large files from Z/os to WIN and backward

[Sam Siegel]

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 Datasets back to the Mainframe we get the follow
> message :
> 553 Cannot send file larger than 4 gigabytes.
> we are trying to understand if the problem is cause from the windows side.
> we do use an SMS Data class so the Datasets will be a multivolume.
>
> 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.
>

Hi Matan,

Here is a link to the FTP protocol specification:
http://www.faqs.org/rfcs/rfc959.html

553 is broken down as follows:

5yz   Permanent Negative Completion reply

x5z File system - These replies indicate the status of the Server file
system vis-a-vis the requested transfer or other file system action.

This appears to be return code issued by the FTP server (appears to be
windows from your description).

The protocol specification provides additional details.

You may need to investigate a different FTP server for the windows machine.

Regards,

Sam


>
> On Mon, May 3, 2010 at 8:38 AM, Timothy Sipples
> wrote:
>
> > What sort of data are in these datasets? A little background on why you're
> > proposing to transfer large datasets (files) might be helpful, too.
> >
> > Also, do you have any sort of requirements for how quickly they need to be
> > transmitted (in both directions)? How often? How reliably? Does the network
> > link (or, for that matter, the data) need to be secured in some way?
> >
> > - - - - -
> > Timothy Sipples
> > Resident Architect (Based in Singapore)
> > STG Value Creation and Complex Deals Team
> > IBM Growth Markets
> > E-Mail: timothy.sipp...@us.ibm.com
> >
> > --
> > 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
> >
>
>
>
> --
> best regards,
> matan cohen
> MF System Administrator.
>
> --
> 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: recommended way to send large files from Z/os to WIN and backward

[Jan MOEYERSONS]

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 Shai Hess's MFNETDISK mean something to you?

Cheers,

Jantje.

--
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: SDSF and MQ

[Richards, Robert B.]

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

The z/OS 1.12 preview announcement letter states the following:

SDSF is designed to support displaying information about printers for JES3,
and to eliminate the requirement for WebSphere(r) MQ when displaying JES2
MAS-wide data on the initiator panel for JES2 once all systems in the MAS
are at z/OS V1.12 JES2. Also, displaying MAS-wide data on the printer panel
for JES2 is planned not to require WebSphere MQ when all systems in the JES2
MAS are at or above z/OS V1.11 JES2.

- Don Imbriale

On Fri, Apr 30, 2010 at 12:32 PM, Richards, Robert B. <
robert.richa...@opm.gov> wrote:

> My boss asked if I could canvass this esteemed group as to whether or not
> it still makes sense to implement the MQ portion of SDSF. We are z/OS 1.10
> going to either 1.11 or 1.12. I've never implemented it before and am
> wondering if I should.
>
> All replies are greatly appreciated.
>
> Bob

--
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

OA29000 and DOM

[Barbara Nitz]

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 AMRF, meaning that a DOM will only remove the 
highlighting from the message so it can roll off the console. *If* that console 
is not set to del=r, anyway. And the DOM will tell commtask to remove it from 
the commtask AMRF queues. (At least, this used to be the case). I don't 
remember (if I ever knew) how a DOM is spread to the subsystems.
-
Now, NetView considers desc 1,2 and 11 action messages by default (which 
we take). But NetView will retain these messages on *it's* internal queues 
until it receives an explicit DOM. Since we installed oa29000, automation 
netview periodically gets DSI374I telling us that so and so many messages 
were queued to the PPT task. At that time, automation netview takes over 
the processor. Looking at the netlog, right around that time an internal 
automation had kicked in that removed the oldest retained messages. Which 
were almost all desc2 messages (and the Netview change talks about desc3 
messages).
-
I tried to find some description of the DOM processing for an AMRF=NO 
installation, but did not see any. Does anyone know
-where to find such a description?
-how this DOM works after console restructure? (If an IBMer is willing to tell, 
the better!
-
And yes, I have an ETR open which is already very lengthy! But unfortunately 
this involves NetView, System Automation and Commtask.
-
Thanks in advance, Barbara

--
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: ETR is down (hilarious resolution)

[Mary Anne Matyaz]

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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: recommended way to send large files from Z/os to WIN and backward

[Finley, Frank]

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 that was a 
more popular File system for Windows boxes, or something written for Home users 
will have that limitation built in so you don't try and transfer the file and 
experience issues with the file system limitation.  

I'd check the Windows box and make certain the file destination is formatted 
NTFS.  You don't have this going to an external drive do you?  Many of them are 
automatically formatted Fat32 for ease of use between Mac, PC, and *nix 
systems.  

If you have access to a Windows 2008 server you can use IIS built in FTPS SSL 
(or Vanilla FTP since at least Windows 2000 if your shop is okay with that) to 
accomplish this transfer if the FTP location is NTFS, otherwise I'd use 
Filezilla Server (It's Open Source and easy to setup).

Frank Finley  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Sam Siegel
Sent: Monday, May 03, 2010 6:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: recommended way to send large files from Z/os to WIN and backward

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 Datasets back to the Mainframe we get the follow
> message :
> 553 Cannot send file larger than 4 gigabytes.
> we are trying to understand if the problem is cause from the windows side.
> we do use an SMS Data class so the Datasets will be a multivolume.
>
> 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.
>

Hi Matan,

Here is a link to the FTP protocol specification:
http://www.faqs.org/rfcs/rfc959.html

553 is broken down as follows:

5yz   Permanent Negative Completion reply

x5z File system - These replies indicate the status of the Server file
system vis-a-vis the requested transfer or other file system action.

This appears to be return code issued by the FTP server (appears to be
windows from your description).

The protocol specification provides additional details.

You may need to investigate a different FTP server for the windows machine.

Regards,

Sam


>
> On Mon, May 3, 2010 at 8:38 AM, Timothy Sipples
> wrote:
>
> > What sort of data are in these datasets? A little background on why you're
> > proposing to transfer large datasets (files) might be helpful, too.
> >
> > Also, do you have any sort of requirements for how quickly they need to be
> > transmitted (in both directions)? How often? How reliably? Does the network
> > link (or, for that matter, the data) need to be secured in some way?
> >
> > - - - - -
> > Timothy Sipples
> > Resident Architect (Based in Singapore)
> > STG Value Creation and Complex Deals Team
> > IBM Growth Markets
> > E-Mail: timothy.sipp...@us.ibm.com
> >
> > --
> > 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
> >
>
>
>
> --
> best regards,
> matan cohen
> MF System Administrator.
>
> --
> 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

--
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: recommended way to send large files from Z/os to WIN and backward

[Lizette Koehler]

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
output files?  I find this helpful when using a server as an holder of data.
DFDSS does not care, but FTP might.

Second, you us IE on a Windows 2003 Server.  Is this IE 8 or 7 or 6?  Each
one has limits

And your problem is not downloading to the server, but returning the file to
the mainframe.  Is that correct?  That it is during the transfer to z/OS
that you receive a 4GB limit message in FTP?  What does the mainframe side
say?  Are there any message in FTP to indicate a Space Allocation error?
Are there any messages in SYSLOG at the time of the failure?  

Which side initiates the FTP from the server to the mainframe?  The windows
system or z/OS?

Lizette


>  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 Datasets back to the Mainframe we get the follow
> message :
> 553 Cannot send file larger than 4 gigabytes.
> we are trying to understand if the problem is cause from the windows
> side.
> we do use an SMS Data class so the Datasets will be a multivolume.
> 
> 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.
> 

--
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: Calculate Tape Bytes to Tracks

[Martin Kline]

>>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 case, wouldn't each member waste slightly less than half a 
track with one half-track block and one short block? The same would apply for 
a file where DISP=MOD adds a little over 27998 bytes each time new data is 
appended. 

--
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: tso session timeout

[Chris Mason]

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 post "LOGONHERE with TSO/E for z/OS V1R11 (Was: tso 
session timeout)" of two days ago in case the needed change of subject 
unfortunately caused it to be missed.

I expect for those who are nervous about introducing "unofficial" software - 
no matter how good the "best efforts" support, the R11 "logonhere" support 
will be appreciated.

Chris Mason

On Mon, 3 May 2010 06:05:10 -0500, Jan MOEYERSONS 
 wrote:

>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 numerous times when we were still 
on
>that Flex box...)
>
>Cheers,
>
>Jantje.

--
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: privilige to run a compress job.

[Staller, Allan]

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.
> >any idea on how can I limit the user to a READ access and still able
them
> to
> >compress the data sets  when needed?
> >
> >note - I don't want them to run the job using a powrful user using
the
> USER
> >statement .
> >
> Would PDSE avoid the problem?  Does Endevor suffer the stale handle
> problem?  Is PDSE ever a solution?
>
> -- gil
>

the migration will be much more complicate .


--
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: Calcul ate Tape B ytes to Tr acks‏

[Staller, Allan]

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 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: Calculate Tape Bytes to Tracks

[John Eells]

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 estimate.

Is there a better way of doing this?  I have over 100,000 tapes to review
and I am trying to make sure I have a good process.

Or is there a different formula I should be using other than
  bytes = lrecl * blksize * blkcnt(and if blkcnt = 0 I
set blkcnt = 1)



As others have observed, the LRECL doesn't matter.

If you will use the same block size for each data sets as was used to 
write it to tape, there is a formula to use to determine how many tracks 
will be used on disk.  But, it is much easier to use one of the 
reference cards' sets of tables that show blocks per track at different 
block sizes for keyed and unkeyed records to predict disk space for 
fixed block data.  If you can't lay hands on a 3390 reference card, or 
find one of the 3390 or later storage books with the same tables, DTS 
has tables in their "Storage Administration z/OS Pocket Reference," and 
perhaps you can find a copy of that.


For variable blocked data, including RECFM=U, I am afraid that by far 
the easiest way to see how much DASD space will be used is to simply 
load the data sets and look afterward.  The distribution of block sizes 
around the mean, and the order in which differently sized blocks occur 
in the data, will affect space utilization considerably.  This could be 
done programattically by reading the tape and calculating the space used 
as the blocks are read but this is a complex undertaking and probably 
not worth the effort.


If you use the largest possible block sizes for variably blocked data, 
you will likely overpredict the amount of DASD space many of them 
require--which might be better than underpredicting it, I suppose.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Calculate Tape Bytes to Tracks

[John Eells]

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 accommodate BDWs and RDWs for 
variable data.  You can find a very long post of mine in the archives 
about block sizes on DASD.


From a space utilization point of view, discounting RECFM=U, the other 
data set parameters have mostly to do with variably-blocked data, the 
amount by which the blocks vary, the distribution of the different block 
sizes, and the order in which they are written.  There are some 
interesting cases (like z/OS fonts) where there is a specific optimum.


For RECFM=U, BLKSIZE=32760 is always best.

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Calculate Tape Bytes to Tracks

[Joel C. Ewing]

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 many
>> bytes are on the tape.  Then dividing that by the number of bytes per track
>> to get a rough estimate.
>>
>> Is there a better way of doing this?  I have over 100,000 tapes to review
>> and I am trying to make sure I have a good process.
>>
>> Or is there a different formula I should be using other than
>> bytes = lrecl * blksize * blkcnt(and if blkcnt = 0 I
>> set blkcnt = 1)
>>
>> Lizette
> 
> 
> 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.
> 
> Also, there has been reported conditions where a BLKSIZE is not reported to
> the tape mgmt system on CLOSE, so the BLKSIZE shows up as zero -- some years
> ago, ADRDSSU and CA-VIEW each exhibited this behavior - since then it's been
> fixed.  For my tape inventory analysis exercises, I used a default of 32760,
> when not reported.
> 
> Scott Barry
> SBBWorks, Inc.
> 
On tape drives with IDRC or other compression, MVS is only aware of
logical blocks sent across the channel, not the physical representation
on the tape (except very indirectly by indicators of % of media used).
My understanding is that with compression, the compressed logical blocks
are assembled by the tape controller into "super blocks" that are
written on the physical tape, but that structure is not communicated
back to MVS because those are issues that are completely handled at the
tape controller level.

For many years (while reporting a blocksize of 0 to the Tape Management
System), ADRDSSU was somehow writing a logical block size of 64 KiB on
3480/3490.  Unless your old ADRDSSU tapes are over a decade old, 32 KiB
is probably too low a value for those.  I remember vaguely when the DSS
change to 64 KiB occurred, because our older stand-alone-IPL DSS tape
wouldn't work on the newer backups and you had to be sure to have a
newer version to be covered for DR.

-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

--
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: RACF - Any way to find out before hand what the user's access is to a file

[Tony @ Comcast]

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
Subject: Re: RACF - Any way to find out before hand what the user's access
is to a file

On Sat, 1 May 2010 11:12:00 -0500, Tony wrote:
>
>1. rdef a surrogat profile USER1.submit and permit ourselves to it.
>2. run a batch job as user=USER1 that would attempt to allocate
>HLQ1.NODE2.WHATEVER.TESTRACF.FILE.
>3. run another job to load a record into said file.
>4. run another job to delete the file.
>
>Any failures would have created ICH408I messages.
>
>Simple, and the price is right.
>
Does it identify the rule by which access was granted?

-- gil

--
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: Calcul ate Tape B ytes to Tr acks

[Lloyd Fuller]

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 under CMS without 
problem, but not under z/OS.

Lloyd  



- Original Message 
From: Paul Gilmartin 
To: IBM-MAIN@bama.ua.edu
Sent: Sun, May 2, 2010 11:38:34 AM
Subject: Re: Calcul ate Tape B ytes to Tr acks

On Sun, 2 May 2010 14:15:48 +, john gilmore wrote:

>IBM is right.
>
>BLKSIZE=32760 is the maximal signed integer value that is 1) not greater than 
>the capacity of a halfword (usually required to avoid control block overflow) 
>and 2) a multiple of 8, 32760 = 4096 x 8 (required for doubleword buffer 
>alignment).
>
Errr... 4095 x 8 ?

But why?  Does channel hardware require that both ends of the buffer
be aligned?  If 32759 works, why not 32767?  Is there a performance
value to alignment?

I believe the CCW allows up to 65535.

-- gil

--
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: 25 reasons why hardware is still hot at IBM

[Anne & Lynn Wheeler]

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 that, and Stanford also developed the world's first
> interactive/dynamic Web application (to access a VM find facility). Since
> then, the variety and scope of Web capabilities for the mainframe has grown
> to become thoroughly complete and incredible. It's not the mainframe's
> fault if you aren't providing Web UIs: it's entirely your (your company's?)
> fault.

1974, CERN made a report of its TSO/CMS comparison (bake-off) available
at SHARE.  The copies available inside the corporation were classified
"CONFIDENTIAL - Restricted" (2nd highest corporate security
classification, available on need-to-know only) ... in attempt to limit
the number of corporate employees that had access to the report (they
couldn't do much about SHARE members that had access to the report).

a couple references to HTML was evolution of SGML (& CMS SCRIPT clone
from waterloo):
http://infomesh.net/html/history/early
http://ref.web.cern.ch/ref/CERN/CNL/2001/001/tp_history/Pr/

GML was invented at the science center in 1969 ... CMS SCRIPT started
out as port of document formating RUNOFF from CTSS (using dot/"."
formating commands). Then GML tag support was added to CMS SCRIPT:
http://www.garlic.com/~lynn/subtopic.html#sgml

discussion of the early Stanford vm/cms web server:
http://www.slac.stanford.edu/history/earlyweb/history.shtml

above discusses using vm/cms webserver to access SPIRES, current
(web) SPIRES)
http://www.slac.stanford.edu/spires/

SPIRES wiki page:
http://en.wikipedia.org/wiki/Stanford_Physics_Information_Retrieval_System

misc. past posts mention TSO/CMS bake-off report:
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran 
as slow as today's supercompu
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2002h.html#14 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002o.html#54 XML, AI, Cyc, psych, and literature
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an 
MVT ABEND 422?
http://www.garlic.com/~lynn/2003c.html#69 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003k.html#13 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
http://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370 was Re: I/O 
Selectric on eBay: How to use?
http://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
http://www.garlic.com/~lynn/2005s.html#26 IEH/IEB/... names?
http://www.garlic.com/~lynn/2006d.html#35 Fw: Tax chooses dead language - 
Austalia
http://www.garlic.com/~lynn/2006d.html#38 Fw: Tax chooses dead language - 
Austalia
http://www.garlic.com/~lynn/2006k.html#34 PDP-1
http://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006v.html#23 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2007d.html#29 old tapes
http://www.garlic.com/~lynn/2007d.html#40 old tapes
http://www.garlic.com/~lynn/2007t.html#40 Why isn't OMVS command integrated 
with ISPF?
http://www.garlic.com/~lynn/2008b.html#65 How does ATTACH pass address of ECB 
to child?
http://www.garlic.com/~lynn/2008j.html#89 CLIs and GUIs

-- 
42yrs virtualization experience (since Jan68), online at home since Mar1970

--
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

Problem with AbendAid 11.2.2

[McKown, John]

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 = 078D0F00 8AF14AB6, IL = 0002, INT = 0001
AB5C4- REGS 0 - 1 = _0666 _430011E3
AB5C4- REGS 2 - 3 = _D008 _0AF050EC
AB5C4- REGS 4 - 5 = _ _
AB5C4- REGS 6 - 7 = _ _
AB5C4- REGS 8 - 9 = _ _
AB5C4- REGS 10 - 11 = _ _0AF147E0
AB5C4- REGS 12 - 13 = _0B129600 _0AF053C8
AB5C4- REGS 14 - 15 = _8AF14964 _
AB5C5- LAST LOADED ABEND-AID MODULE WAS #XAAHEAD

Does this look familar to anyone? I do have a ticket opened with Compuware.

John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


--
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: Problem with AbendAid 11.2.2

[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 all appears to be well.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

(9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John
> Sent: Monday, May 03, 2010 9:41 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Problem with AbendAid 11.2.2
> 
> 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 = 078D0F00 8AF14AB6, IL = 0002, INT = 0001
> AB5C4- REGS 0 - 1 = _0666 _430011E3
> AB5C4- REGS 2 - 3 = _D008 _0AF050EC
> AB5C4- REGS 4 - 5 = _ _
> AB5C4- REGS 6 - 7 = _ _
> AB5C4- REGS 8 - 9 = _ _
> AB5C4- REGS 10 - 11 = _ _0AF147E0
> AB5C4- REGS 12 - 13 = _0B129600 _0AF053C8
> AB5C4- REGS 14 - 15 = _8AF14964 _
> AB5C5- LAST LOADED ABEND-AID MODULE WAS #XAAHEAD
> 
> Does this look familar to anyone? I do have a ticket opened 
> with Compuware.
> 
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * (817)-961-6183 cell
> john.mck...@healthmarkets.com * www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain 
> confidential or proprietary information. If you are not the 
> intended recipient, please contact the sender by reply e-mail 
> and destroy all copies of the original message. 
> HealthMarkets(r) is the brand name for products underwritten 
> and issued by the insurance subsidiaries of HealthMarkets, 
> Inc. -The Chesapeake Life Insurance Company(r), Mid-West 
> National Life Insurance Company of TennesseeSM and The MEGA 
> Life and Health Insurance Company.SM
> 
> 
> --
> 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: recommended way to send large files from Z/os to WIN and backward

[Don Melton]

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/server set-up that you used to send the file to Windows in the first 
place.]

-- 
be seeing you ... Don
Don Melton, Sr. Consultant, Vatic Technologies Limited
"Matan Cohen"  wrote in message 
news:j2xeb22b34b1005030348h8c7e0c3fj20ad9c421a5a4...@mail.gmail.com...
> 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 Cannot send file larger than 4 gigabytes.
> we are trying to understand if the problem is cause from the windows side.
> we do use an SMS Data class so the Datasets will be a multivolume.
>
> 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.
>
>
>
> On Mon, May 3, 2010 at 8:38 AM, Timothy Sipples
> wrote:
>
>> What sort of data are in these datasets? A little background on why 
>> you're
>> proposing to transfer large datasets (files) might be helpful, too.
>>
>> Also, do you have any sort of requirements for how quickly they need to 
>> be
>> transmitted (in both directions)? How often? How reliably? Does the 
>> network
>> link (or, for that matter, the data) need to be secured in some way?
>>
>> - - - - -
>> Timothy Sipples
>> Resident Architect (Based in Singapore)
>> STG Value Creation and Complex Deals Team
>> IBM Growth Markets
>> E-Mail: timothy.sipp...@us.ibm.com
>>
>> --
>> 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
>>
>
>
>
> -- 
> best regards,
> matan cohen
> MF System Administrator.
>
> --
> 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: Calculate Tape Bytes to Tracks

[Paul Gilmartin]

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.

>For RECFM=U, BLKSIZE=32760 is always best.
>
Only if the application exploits track balancing.  If the application
simply fills each physical record to BLKSIZE, half-track is better.
E.g.:

//STEPEXEC  PGM=IEBGENER
//SYSUT1  DDFILEDATA=BINARY,RECFM=U,BLKSIZE=32760,PATH='...'
//SYSUT2  DDUNIT=SYSALLDA,...

... would be better with BLKSIZE=27998.

The capacity table is in, e.g.:

   Linkname: B.1.2 "Using IBM 3390 in an MVS Environment"
URL: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/AM3U1001/B.1.2

-- gil

--
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: Problem with AbendAid 11.2.2

[Chase, John]

> -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
> all appears to be well.

"Old stuff" forgotten in MLPA can cause head-scratching, too.  :-)

-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: How to analyze a volume's access by dataset

[Bill Fairchild]

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 about 
it.  FastDASD, marketed by CA the last I heard, does all that by sampling, not 
tracing, the DASD addresses used by most access methods, then reads the VTOC to 
determine in which data set each I/O occurred.  I used to be involved with 
FastDASD, and may even have added support for GTF input, but if so, it was too 
long ago for my mercury delay line memory cells to remember.

TMON/MVS, on the other hand, gets the CCHRs by intercepting I/Os rather than 
sampling z/OS control blocks.  Its analysis is thus far more accurate, but the 
amount of data analyzed is much smaller than is capable with FastDASD.

I'm not sure how unabridged the SMF records are; i.e., probably not all I/Os 
are accounted for, especially those done by the operating system and/or exotic 
subsystems using low-level access methods.  Both TMON/MVS and FastDASD are 
capable of catching such SMF-avoiding I/Os as long as they are done by 
components that put the I/O's starting DASD seek address in the IOSB, but that 
is not required of authorized programs that do I/O.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Longnecker, Dennis
Sent: Friday, April 30, 2010 6:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How to analyze a volume's access by dataset

TMON/MVS gives us that information for a real time snapshot.  Can either start 
a summary or detail I/O trace and look at the trace once it is completed.  I 
imagine a GTF I/O would be able to also get you that information, but since we 
have TMON, we use that.

Dennis

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
John Norgauer
Sent: Friday, April 30, 2010 3:01 PM
To: IBM-MAIN@bama.ua.edu
Subject: How to analyze a volume's access by dataset

Is there any software available that will show the access by dataset(or by 
CCHR)  for a given volume?



John Norgauer
Senior Systems Programmer
Mainframe Technical Support Services
University of California Davis Medical Center
2315 Stockton Blvd
ASB 1300
Sacramento, Ca 95817
916-734-0536

 SYSTEMS PROGRAMMING..  Guilty, until proven innocent !! "JN  2004

"Hardware eventually breaks - Software eventually works"  anon


--
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

--
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: ETR is down (hilarious resolution)

[Scott T. Harder]

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 should be a no-brainer full of ease.  IBMLink is certainly not the
only weak link in the chain, here, as we all know very well.  Name a
company; it ain't an easy thing to do.  But, those with the resources of the
larger companies have far fewer excuses, AFAIC.

Just my $0.02,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Bob goolsby
> Sent: Thursday, April 29, 2010 10:33 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: ETR is down (hilarious resolution)
> 
> Tom --
> 
> Let me get this right -- They want you to sanitize your text so Their
> "system" will let you send then a Trouble Ticket?  Their "system"
> can't handle 'special characters'?
> 
> So, what do they do with someone whose Locale isn't ISO 8859-1?  Let
> us say 850 (LATIN-1 with Euro-symbol) or 863 (French Canadian)?  I
> really want to see them tell a Francophone Quebeker that they have to
> submit the ETR in English
> 
> 
> B
> 
> On Thu, Apr 29, 2010 at 7:13 AM, Pinnacle 
> wrote:
> > - Original Message - From: "Pinnacle"
> 
> > Newsgroups: bit.listserv.ibm-main
> > Sent: Thursday, April 29, 2010 9:50 AM
> > Subject: ETR is down
> >
> >
> >> FYI,
> >>
> >> Getting "internal error occurred" trying to submit an ETR.
> >>
> >> Regards,
> >> Tom Conley
> >>
> >
> > Called IBMLink support in Bangalore, and found out my problem.  Before I
> > even finished saying, "internal error has occurred, I was told to
> "remove
> > all special characters" from the ETR, "remove excess blank lines", and
> > "shorten long sentences".  I had copied in a panel, and the underscores
> at
> > the top of the panel below the menu were all changed to cent signs.  I
> > deleted all the cent signs, and viola!  My ETR submitted.
> >
> > I did mention to the Level 1 person that an error message telling me to
> > "remove all special characters" would have been more helpful than
> "internal
> > error has occurred".
> >
> > I love IBMLink.
> >
> > Regards,
> > Tom Conley
> > --
> > 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
> >
> 
> 
> 
> --
> 
> Bob Goolsby
> bob.gool...@gmail.com
> 
> --
> 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

MVS to z/OS Experience Looking for Work

[Scott T. Harder]

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 *anywhere* in the good ol' USA.  I am currently in
Naples, FL and hate the idea of leaving, but will do it.  Of course,
telecommuting is an even better idea!  I would be more than willing to spend
time at a location for whatever period required, initially; prior to the
beginning of a telecommuting situation.

If anyone knows of any potential openings at companies where I could send my
resume, please let me know offline and I will be eternally grateful.

Thanks for your time,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

--
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: Problem with AbendAid 11.2.2

[Elardus Engelbrecht]

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 concatenations also can cause 
some havoc if you're not careful.

This is why STEPLIB is very handy to test out new version and then when 
ready to upgrade, you review the Linklist+LPA and drop STEPLIB.

For myself, I caused an uneeded re-IPL because of an overlooked ICHRDSNT 
and other modules... it still hurts after many moons... ;-D

Groete / Greetings
Elardus Engelbrecht

--
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: Calculate Tape Bytes to Tracks

[Bill Fairchild]

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 automatically 
recorded by these access methods.  And SMF data might not be automatically 
recorded either, depending on the specific low-level access method used, 
whether the program is authorized or not, etc.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Thompson, Steve
Sent: Sunday, May 02, 2010 4:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calculate Tape Bytes to Tracks

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Sunday, May 02, 2010 4:00 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calculate Tape Bytes to Tracks

>someone will correct me if I am incorrect - but i believe that the
maximum 
blocksize on DASD (3390-compatible) to assure 2 blocks per track is
27998

That is correct.
But, that is not the statement I was responding to.
IBM allows you to shoot yourself in the foot, and you can specify a
blocksize greater than 27998.

BTW, you can specify greater than 32760.
I specify 32767 with SMF data all the time on disk.



Since you bring it up indirectly, shouldn't LBI allow for full track
writes?

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

--
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

(may or may not be on topic) Floating point arithmetic

[Ed Gould]

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 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: Calculate Tape Bytes to Tracks

[Bill Fairchild]

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 program to use 
XDAP to keep writing more and more blocks on the same track until I got an I/O 
error, at which point I would know how many fit successfully on the track.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Paul Gilmartin
Sent: Sunday, May 02, 2010 11:34 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calculate Tape Bytes to Tracks


Where's the track capacity formula?

-- gil

--
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: recommended way to send large files from z/OS to WIN and backward

[Ron Hawkins]

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 Hawkins [mailto:ron.hawkins1...@sbcglobal.net]
> Sent: Sunday, May 02, 2010 10:03 AM
> To: 'IBM Mainframe Discussion List'
> Subject: RE: [IBM-MAIN] recommended way to send large files from z/OS to
WIN
> and backward
> 
> Martin,
> 
> I've used XP PRO and VISTA PRO to FTP 8000+ CYL files to and from z/OS 1.9
> using DSNTYPE=LARGE. It works no problem, and I assume it will work with
later
> versions of Windows and z/OS.
> 
> When sending Windows to z/OS I used pre-allocated datasets, but you could
use
> an SMS DATACLAS to get the correct attributes.
> 
> Ron
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf
> Of
> > Lizette Koehler
> > Sent: Sunday, May 02, 2010 4:41 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: [IBM-MAIN] recommended way to send large files from Z/os to
WIN
> > and backward
> >
> > Matan,
> >
> > I guess I would need to know more about your environment.
> >
> > For windows - what version
> > From mainframe - z/OS V1.??
> >
> > Do you have other products like NDM, XCOM, etc on Mainframe/Open
Systems???
> >
> > Do you use IE, Mozilla, filezilla on Windows?
> > Do you have any limitations on the Server for transfers?  Some shops
might
> > limit the amount transferred in one session due to constraints on the
> > network.
> >
> > What I remember, for filesystem limitations, on Windows machines,
limitation
> > on the system depends on the FileSystem used:
> >
> > - FAT16 = 2GB limit;
> >
> > - FAT32 = 4GB minus 2 bytes max limit.
> >
> > - NTFS = 2TB (that's terrabytes)
> >
> > So depending on your components, it might be possible.
> >
> > Lizette
> >
> >
> > > Matan Cohen Wrote:
> > >
> > > I'm searching for a way to send a large data sets (over 4 GB ) to
> > > Windows ,
> > > the main purpose is to avoid using XMIT on the Data Sets so i prefer
> > > not
> > > using FTP.
> > > The Datasets are DFDSS dumps and I need to ensure I can returned them
> > > into
> > > the Z/OS in case they are needed.
> > > Is it possibale not using XMIT while transfering Data sets?
> > > is there a way to able the Z/os FTP to get data sets larger then 4 GB?
> >
> > --
> > 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: Calculate Tape Bytes to Tracks

[John Eells]

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)/232

D = 9 + (DL + 6DN + 6)/34

  Where: DN = (DL + 6)/232

Each result is rounded up to the nearest integer.

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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 analyze a volume's access by dataset

[Ron Hawkins]

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 after CA bought
Legent.

It used to have a pretty good LRU cache modeler built in. I wonder if it
still works and supports 512GB or more of cache?

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Bill Fairchild
> Sent: Monday, May 03, 2010 8:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] How to analyze a volume's access by dataset
> 
> 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 about
it.
> FastDASD, marketed by CA the last I heard, does all that by sampling, not
> tracing, the DASD addresses used by most access methods, then reads the
VTOC
> to determine in which data set each I/O occurred.  I used to be involved
with
> FastDASD, and may even have added support for GTF input, but if so, it was
too
> long ago for my mercury delay line memory cells to remember.
> 
> TMON/MVS, on the other hand, gets the CCHRs by intercepting I/Os rather
than
> sampling z/OS control blocks.  Its analysis is thus far more accurate, but
the
> amount of data analyzed is much smaller than is capable with FastDASD.
> 
> I'm not sure how unabridged the SMF records are; i.e., probably not all
I/Os
> are accounted for, especially those done by the operating system and/or
exotic
> subsystems using low-level access methods.  Both TMON/MVS and FastDASD are
> capable of catching such SMF-avoiding I/Os as long as they are done by
> components that put the I/O's starting DASD seek address in the IOSB, but
that
> is not required of authorized programs that do I/O.
> 
> Bill Fairchild
> 
> Software Developer
> Rocket Software
> 275 Grove Street * Newton, MA 02466-2272 * USA
> Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
> Email: bi...@mainstar.com
> Web: www.rocketsoftware.com
> 
> 

--
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: (may or may not be on topic) Floating point arithmetic

[McKown, John]

> -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 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

It definetly does apply to IBM z hardware. Also if you use HFP (Hex Floating 
Point - legacy) and BFP (IEEE floating point), then the identical operation can 
have two different answers, neither of which is necessarily "correct".

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
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: MVS to z/OS Experience Looking for Work

[Ron Hawkins]

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 advertisement.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Scott T. Harder
> Sent: Monday, May 03, 2010 8:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: [IBM-MAIN] MVS to z/OS Experience Looking for Work
> 
> 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 *anywhere* in the good ol' USA.  I am currently in
> Naples, FL and hate the idea of leaving, but will do it.  Of course,
> telecommuting is an even better idea!  I would be more than willing to
spend
> time at a location for whatever period required, initially; prior to the
> beginning of a telecommuting situation.
> 
> If anyone knows of any potential openings at companies where I could send
my
> resume, please let me know offline and I will be eternally grateful.
> 
> Thanks for your time,
> 
> Scott T. Harder
> Mainframe Services, Inc.
> Naples, FL
> 
> --
> 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

--
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: Calculate Tape Bytes to Tracks

[John Eells]

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 aren't additional.


Hmmm...I thought they were, so that what you specified was the "logical" 
block length, as is true for RDWs, but I cannot find it documented 
quickly.  I'll see if I can find someone who knows for sure.  They are 
certainly part of the physical block that is written; the question is 
whether they are added to what you specify or subtracted from what you 
specify.





For RECFM=U, BLKSIZE=32760 is always best.


Only if the application exploits track balancing.  If the application
simply fills each physical record to BLKSIZE, half-track is better.
E.g.:


Everything I know of on z/OS that uses RECFM=U uses TRKBAL to determine 
when to write short blocks (which, by the way, returns the balance of 
remaining track capacity; I'm not sure I would call this "balancing").


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.





The capacity table is in, e.g.:

Linkname: B.1.2 "Using IBM 3390 in an MVS Environment"
 URL: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/AM3U1001/B.1.2


Good current reference.  In Topic B.1.1.1 is the track capacity formula 
you asked about in another post, which appears at first glance to be 
identical to the one I posted in response.




--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Calculate Tape Bytes to Tracks

[John Eells]

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 BDW and RDWs; they aren't additional.


Hmmm...I thought they were, so that what you specified was the "logical"
block length, as is true for RDWs, but I cannot find it documented
quickly. I'll see if I can find someone who knows for sure. They are
certainly part of the physical block that is written; the question is
whether they are added to what you specify or subtracted from what you
specify.



Turns out you're right, and I've been wrong about this for nearly 20 years.

The real reason is that the system rounds buffer space requests up to a 
doubleword boundary.  32760 rounds up to 32768, which is one byte more 
than can be represented by a 16-bit signed value.

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Calculate Tape Bytes to Tracks

[John Kelly]

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 blocks on the tape, the IDRC number of blocks is 
lower of course.

I know you've had numerous replies about arithmetic and geometry but I'd 
also suggest that you lokk for bad block sizes on tapes, users and 
installations seem less careful with tape block sizes. And as has been 
mentioned watch out or exclude 'system' tapes, eg DSS, HSM, etc.

Jack Kelly
202-502-2390 (Office)

--
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: Problem with AbendAid 11.2.2

[Scott T. Harder]

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 because of an overlooked ICHRDSNT
> and other modules... it still hurts after many moons... ;-D
> 
> Groete / Greetings
> Elardus Engelbrecht

--
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 analyze a volume's access by dataset

[Bill Fairchild]

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 acquisition of Legent.

"It used to have a pretty good LRU cache modeler built in."  Assuming that "it" 
means FastDASD, then I don't remember the upper limit on the supported cache 
size.  Supporting that function was one of my all-time favorite projects.  And 
thanks for the honorable mention.

Bill Fairchild

[Most nouns and adjectives can easily be verbed, as in "The operator onlined 
the volume".]

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ron Hawkins
Sent: Monday, May 03, 2010 11:21 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How to analyze a volume's access by dataset

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 after CA bought
Legent.

It used to have a pretty good LRU cache modeler built in. I wonder if it
still works and supports 512GB or more of cache?

Ron

--
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: Calculate Tape Bytes to Tracks

[Ted MacNEIL]

>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 change with the version of LE that 
came out with z/OS 1.4.
-
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: MVS to z/OS Experience Looking for Work

[Itschak Mugzach]

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
> 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 advertisement.
>
> Ron
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of
> > Scott T. Harder
> > Sent: Monday, May 03, 2010 8:44 AM
> > To: IBM-MAIN@bama.ua.edu
>  > Subject: [IBM-MAIN] MVS to z/OS Experience Looking for Work
> >
> > 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 *anywhere* in the good ol' USA.  I am currently in
> > Naples, FL and hate the idea of leaving, but will do it.  Of course,
> > telecommuting is an even better idea!  I would be more than willing to
> spend
> > time at a location for whatever period required, initially; prior to the
> > beginning of a telecommuting situation.
> >
> > If anyone knows of any potential openings at companies where I could send
> my
> > resume, please let me know offline and I will be eternally grateful.
> >
> > Thanks for your time,
> >
> > Scott T. Harder
> > Mainframe Services, Inc.
> > Naples, FL
> >
> > --
> > 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
>
> --
> 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

Red Alert: z/OS with PTFs for OA30513 can experience data loss (2010.05.03)

[Knutson, Sam]

*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 datasets that are not eligible for deletion


Description: With OA30513 applied, Logger dataset delete processing does
not properly maintain the lowest valid point in the logstream leading to
data loss. The following describes the circumstances when the problem
can occur:

PTFs for OA30513 are applied 
A logstream has allocated many offload datasets and is using more than
one dataset directory or dataset directory extent 
This logstream is defined with AUTODELETE(YES) and a non-zero retention
period (RETPD) 
OR 

This logstream is defined with AUTODELETE(NO), and the logstream's data
is being trimmed 
When these conditions are met, there is a code defect where Logger can
delete more datasets than it should. Applications attempting to browse
the logstream can get back a gap condition or an error indicating the
requested data cannot be found. 

There are no Logger messages or displays that will externalize the loss
of data. Please see APAR OA32737 for further details. 
Recommended Actions:Option 1: Restore the PTFs for OA30513. Going back
to the environment pre-OA30513 will remove the exposure to data loss. 

Option 2: Contact the support center for a ++APAR.








This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
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: (may or may not be on topic) Floating point arithmetic

[Tom Marchant]

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 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'1000' by X'A' and you will get 
X'199'.  Multiply that by X'A' and see what you get. 
The windoze hex calculator gives X'FFA'.

Decimal Floating Point doesn't have this problem.  IIRC, DFP 
was first implemented on the z9 and on the z10 it is 
implemented entirely in hardware.

-- 
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: Red Alert: z/OS with PTFs for OA30513 can experience data loss (2010.05.03)

[Jousma, David]

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 Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Knutson, Sam
Sent: Monday, May 03, 2010 2:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: Red Alert: z/OS with PTFs for OA30513 can experience data loss
(2010.05.03)

*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 datasets that are not eligible for deletion


Description: With OA30513 applied, Logger dataset delete processing does
not properly maintain the lowest valid point in the logstream leading to
data loss. The following describes the circumstances when the problem
can occur:

PTFs for OA30513 are applied 
A logstream has allocated many offload datasets and is using more than
one dataset directory or dataset directory extent 
This logstream is defined with AUTODELETE(YES) and a non-zero retention
period (RETPD) 
OR 

This logstream is defined with AUTODELETE(NO), and the logstream's data
is being trimmed 
When these conditions are met, there is a code defect where Logger can
delete more datasets than it should. Applications attempting to browse
the logstream can get back a gap condition or an error indicating the
requested data cannot be found. 

There are no Logger messages or displays that will externalize the loss
of data. Please see APAR OA32737 for further details. 
Recommended Actions:Option 1: Restore the PTFs for OA30513. Going back
to the environment pre-OA30513 will remove the exposure to data loss. 

Option 2: Contact the support center for a ++APAR.




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: (may or may not be on topic) Floating point arithmetic

[Howard Brazee]

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'1000' by X'A' and you will get 
>X'199'.  Multiply that by X'A' and see what you get. 
>The windoze hex calculator gives X'FFA'.

In the same way, we cannot accurately represent the number 1/3 in
decimal.   Except we're used to this bit of inaccuracy so it doesn't
bother us.

--
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: EKM at z/OS 1.11

[Richard Peurifoy]

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 / 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: (may or may not be on topic) Floating point arithmetic

[Bob goolsby]

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 the title "I Found a Bug In Perl -- when I add 0.50 to 1.75 I
get 2.25001!")  I trot out Goldberg's explanation of
non-terminating binary fractions and hand them the URL.  I also point
to them that 2 - 2 = 0, but 2 - 1.0*2 doesn't


B



On Mon, May 3, 2010 at 1:13 PM, Howard Brazee  wrote:
> 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'1000' by X'A' and you will get
>>X'199'.  Multiply that by X'A' and see what you get.
>>The windoze hex calculator gives X'FFA'.
>
> In the same way, we cannot accurately represent the number 1/3 in
> decimal.   Except we're used to this bit of inaccuracy so it doesn't
> bother us.
>
> --
> 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
>



-- 

Bob Goolsby
bob.gool...@gmail.com

--
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: Calcul ate Tape B ytes to Tr acks

[Bill Fairchild]

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 0 on a 3390 is 
56664.

Since day 1 of System/360 in the mid-1960s, IBM had a DASD CCW command code 
called Write Special Count, Key and Data, in which a single DASD block could be 
written that was larger than the maximum track capacity.  This type of record 
would overflow onto enough subsequent tracks to hold all the data, but the 
total length of the data field in this type of block could not be greater than 
65535.  This command was not supported on the 3380 or 3390.

But far more than 56K bytes can be written in one DASD channel program.  The 
most, however, that can fit on any one track is 56K.  Any number of tracks can 
be written in the same I/O request.

Regarding tape block sizes, the largest amount of tape data that can be written 
with one CCW is 65535.  But any number of CCWs can be data chained together to 
produce a single tape block of any huge size imaginable.  I once wrote a 
program to read a tape with 640K byte blocks on it and reblock the data into 
QSAM-compatible chunks of 32K or less.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Paul Gilmartin
Sent: Sunday, May 02, 2010 10:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calcul ate Tape B ytes to Tr acks


I believe the CCW allows up to 65535.

-- gil
--
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

Catalog re-location

[John Norgauer]

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)?



John Norgauer
Senior Systems Programmer
Mainframe Technical Support Services
University of California Davis Medical Center
2315 Stockton Blvd
ASB 1300
Sacramento, Ca 95817
916-734-0536

 SYSTEMS PROGRAMMING..  Guilty, until proven innocent !! "JN  2004

"Hardware eventually breaks - Software eventually works"  anon


--
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: ZFS

[Bill Fairchild]

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 it with a dump.  
It took many minutes more of being CPU bound to generate the SYSUDUMP output, 
which contained hundreds of thousands of lines of output, almost all of which 
was the formatted RB chain.  My MVS sandbox system did not crash, but I did not 
let this job run until "completion" either, so I don't know what would have 
happened on that primitive version of MVS.  I believe, however, that your 
snippet would have caused my MVT sandbox, if I had tested it there, to crash, 
as explained next.

The first instruction, a BALR, puts the address of the next instruction, an 
SVC, into R15.  The SVC 12 instruction, on any variant of OS/360 or its 
successors (PCP, MFT, MVT, SVS, VS1, VS2, MVS, ESA, S/390, z/OS, etc.) is the 
result of coding a SYNCH macro.  The diagnostics book says that an SVC 12 
causes a new RB to be chained off the current TCB and then control passes to 
the address in R15 with the newly built RB set up as the current RB.  So these 
two instructions cause an infinite loop that builds RBs forever until there is 
no more available virtual storage with which to build the next RB.

In MVS, RBs are built in LSQA, I believe, and when that resource is exhausted 
and more is needed, I believe that today's MVS, much more RAS-hardened than it 
was in 1977, will ABEND the current piece of work with an ABEND code reflecting 
that all requested CPU time had been used (an Sx22) and the system and all 
other work will keep running blissfully unaware of the virus Godzilla that 
almost swallowed Cleveland.  MVT, however, built RBs with real storage, as MVT 
had no virtual storage.  Real storage can be gobbled up much faster than 
virtual storage.  And when MVT wanted to build the impossible next RB, it would 
crash rather than ABEND the current piece of work.  I think.  A clever sysprog, 
with luck and a lot of time spent looking at the standalone dump, could find 
out which program had crashed MVT, but he couldn't prevent this from happening 
again and again.

It was intolerable that any normal user could run an unauthorized copy of your 
snippet and crash the whole system.  Ignorance of such black holes in the 
system's design was what kept some MVTs up and running.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Sunday, May 02, 2010 8:25 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ZFS
In <629a420612b49a4a96f9c143f22230781b01285...@mbx04.cgcent.miami.edu>, on
04/28/2010
   at 07:37 PM, "Martinez, Frank J"  said:

>MVT was not broken.

 05F0
 0A0C
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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

--
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: (may or may not be on topic) Floating point arithmetic

[Paul Gilmartin]

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 comes up about once a month on the Perl boards (usually
>under the title "I Found a Bug In Perl -- when I add 0.50 to 1.75 I
>get 2.25001!")  I trot out Goldberg's explanation of
>non-terminating binary fractions and hand them the URL.  I also point
>to them that 2 - 2 = 0, but 2 - 1.0*2 doesn't
>
I'm calling that simply incompetent display-to-numeric conversion,
since all the operands and results can be represented exactly in
either binary or decimal with a reasonable number of digits.

I agree with the complainers; it's a bug.

>On Mon, May 3, 2010 at 1:13 PM, Howard Brazee wrote:
>> On 3 May 2010 11:42:47 -0700, (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'1000' by X'A' and you will get
>>>X'199'.  Multiply that by X'A' and see what you get.
>>>The windoze hex calculator gives X'FFA'.
>>
I'd attribute that to hex arithmetic's assuming integers and
discarding fractional parts.  Perhaps it's working as specified.

>> In the same way, we cannot accurately represent the number 1/3 in
>> decimal.   Except we're used to this bit of inaccuracy so it doesn't
>> bother us.
>>
An earlier ply referred to a "problem" with binary floating
point.  "Problem" is inappropriate; "limitation" would be
better.  And as you point out, the limitation persist
with DFP; merely its domain has been narrowed.

For divisors which are some large powers of two, DFP will
truncate the result while IEEE/HFP with the same number of
bits stored will give exact results.

There are rational arithmetic subroutine packages, some with
variable precision, which will exactly represent any rational
number within the supported range.

It's naive to believe that DFP is free of roundoff error,
or even that it generally has less roundoff error than
IEEE/HFP; however it simplifies coding to GAAP requirements.

-- gil

--
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: (may or may not be on topic) Floating point arithmetic

[Clark Morris]

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/
>>
>
>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'1000' by X'A' and you will get 
>X'199'.  Multiply that by X'A' and see what you get. 
>The windoze hex calculator gives X'FFA'.
>
>Decimal Floating Point doesn't have this problem.  IIRC, DFP 
>was first implemented on the z9 and on the z10 it is 
>implemented entirely in hardware.

And the IBM COBOL people don't feel there is a need to implement it
despite IBM having spent a bundle to help define it and then implement
it in hardware.  If they do, they intend to use the same USAGE most
people would use to mean IEEE binary floating point.  ARRGH

--
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: Munged Subject [Calcul ate Tape B ytes to Tr acksþ]

[Bill Godfrey]

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 the subject and the message was replied to a 
second time by John.

I tried to figure out what would cause a space to be added after every 
10 characters, and what connection it might have with the windows-
1256 charset, which Don Poitras noticed was being used in John's 
messages.

After searching for examples of usage of windows-1256 in mail, I came 
upon this website, which is not about technical issues with mail or 
character sets, but birdwatching, of all things.

http://www.virtualbirder.com/bmail/gabol/200912/02/

One of the emails on the web page has a subject that looks like this:

Subject: =?windows-1256?Q?Sandhill_C?=
 =?windows-1256?Q?ranes_this?=
 =?windows-1256?Q?_evening_a?=
 =?windows-1256?Q?t_Flowing_?=
 =?windows-1256?Q?Well_Road_?=
 =?windows-1256?Q?cypress_po?=
 =?windows-1256?Q?nd_(Doughe?=
 =?windows-1256?Q?rty_County?=
 =?windows-1256?Q?)=FE?=

The subject has been broken up into 9 "encoded words", as defined by 
RFC 2047, and each encoded word contains exactly 10 characters of 
original text. Email software that supports RFC 2047 should decode 
these encoded words and display only the resulting text. Notice that 
the encoded words are separated from each other by whitespace. (I 
used a separate line for each in this post). RFC 2047 says that 
whitespace between adjacent encoding words should be ignored.

As an aside, I might point out that RFC 2047 does not say anything 
about making a separate encoded word every 10 characters. It says an 
encoded word can be up to 75 characters long. So it appears that some 
mail software was written to produce a new encoded word for every 10 
characters, for reasons unknown. 

What if John's messages are being encoded just like this message on 
the birdwatching website? And suppose the messages are being 
received on a mail server that is NOT ignoring the whitespace between 
the encoding words, but is putting in a space between the results of 
decoding adjacent encoded words as it decodes the subject. The result 
would be exactly what we are seeing.

There is a lot of supposition in what I am saying, but it does provide 
one explanation.

One other thing - the hex FE at the end in the sample subject above. I 
suspect that John's encoded subject lines, like the sample above, end 
with a hex FE, which in Windows-1256 is a code for "right-to-left mark". 
Even though it is not needed for western text, it seems to be left in 
there, and sometimes ends up being treated as an ISO-8859-1 hex FE, 
which is a "thorn" character, which can be seen in the subject line of a 
post that Elardus Engelbrecht made on this subject.

Bill

On Sun, 2 May 2010 13:39:44 -0400, Steve Thompson wrote:

>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-
m...@bama.ua.edu] On Behalf Of john gilmore
>Sent: Sunday, May 02, 2010 9:16 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: Calcul ate Tape B ytes to Tr acksþ
>
>I have been watching subject lines get munged for a while. And so I 
thought I'd try to track it down.
>
>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 Tracksþ
>
>And with John's first reply it became:
>
>Calcul ate Tape B ytes to Tr acksþ
>
>Anyone have any idea what would do this?

--
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: recommended way to send large files from Z/os to WIN and backward

[Peter Bishop]

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 the follow
>message :
>553 Cannot send file larger than 4 gigabytes.
>we are trying to understand if the problem is cause from the windows side.
>we do use an SMS Data class so the Datasets will be a multivolume.
>

Hi,

Have you tried FileZilla?

Thoroughly recommended, works on Vista, and the price is right.

http://filezilla-project.org/ if you're interested.

cheers
Peter

--
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