Re: 25 reasons why hardware is still hot at IBM

Sometimes I like topic drift. :-) Yes, there are occasions when (well designed) 3270 user interfaces can provide productivity benefits over even reasonably well designed Web user interfaces. Many airline check-in counters and many industries' call centers still use 3270 user interfaces for precise

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

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

Steven Liston/IS/SLC/StandardLifeGroup is out of the office.

I will be out of the office starting 03/05/2010 and will not return until 04/05/2010. Please contact the TST MF mailbox for any urgent requests. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to l

Re: Calculate Tape Bytes to Tracks

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 num

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

On 2 May 2010 04:31, 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. I don't see the connection... Both z/OS and Windows handle > 4GB without much trouble, ass

Re: Calculate Tape Bytes to Tracks

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

Re: Calculate Tape Bytes to Tracks

On Mon, 3 May 2010 00:05:58 +0800, Brian Fraser wrote: > >For some fixed length records, 27998 (or half-track) would not be the >most efficient use of the track.. > >Suppose a record length of 800... at half track you'd only get 68 >records on a track, 2 blocks of 27200. > >But if you instead used

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

In article you wrote: > Steve's question is an interesting one. > > As the culpable party, or at least the source of the first munged title, the > only light I can shed on it is that the copy of that post in my sent folder > is not munged. > > It also remains unmunged when I send a copy of

Re: Calculate Tape Bytes to Tracks

>>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? I would assume so, but I was massaging SMF data long before LBI came along. - Too busy driving to stop for gas! --

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

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

Re: Calculate Tape Bytes to Tracks

W dniu 2010-05-02 17:16, Ted MacNEIL pisze: IBM says it's 32760. Typo on my part. BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset parameters. Sometimes? When is it not? Yes, sometimes. *Usually* SDB (System Determined Blocksize) is approx half track, but: a) It's n

Re: Calculate Tape Bytes to Tracks

>>Remember that the maximum blksize on dasd is 27998 ... >No. It's not. >It's 32765. 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 Chris Hoelscher IDMS/DB2 Database Architect Humana Inc 502-47

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

Steve's question is an interesting one. As the culpable party, or at least the source of the first munged title, the only light I can shed on it is that the copy of that post in my sent folder is not munged. It also remains unmunged when I send a copy of it to myself, but that trip is a

Munged Subject [Calcul ate Tape B ytes to Tr acks‏]

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

Re: Calculate Tape Bytes to Tracks

On Mon, 3 May 2010 00:05:58 +0800, Brian Fraser wrote: > >For some fixed length records, 27998 (or half-track) would not be the >most efficient use of the track.. > Hmmm... I see: 4.1.26.1.3 "z/OS V1R10.0 DFSMShsm Storage Administration Guide" + BLKSIZE=28332 is the capacity of half a

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

Re: privilege to run a compress job.

Martin, You can accomplish compression by migrate/recall of a PDS. The user doing this needs HSM rights, but is not granted access to the dataset itself. It has the advantage of not working if the dataset is open by another address space - no one get fragged as you would with DISP=SHR and IEBCOPY

Re: Calculate Tape Bytes to Tracks

On Mon, 3 May 2010 00:05:58 +0800, Brian Fraser wrote: >> >>>BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset >>>parameters. >> >> Sometimes? >> When is it not? SDB chooses 32760 for RECFM=U. I suppose this is wise, although it seems to presume that the application will exp

Re: Calcul ate Tape B ytes to Tr acks‏

Mea culpa maxima: 32760 = 4095 x 8. 32760 is the largest multiple of 8 that is less than or equal to 2^15 - 1 = 32767, the capacity of a signed halfword. The alignment of a buffer on a doubleword boundary does confer small performance advantages in some circumstances. More important, it

Re: privilige to run a compress job.

On 5/2/2010 10:08 AM, Paul Gilmartin wrote: On Sun, 2 May 2010 11:15:12 +0300, Matan Cohen wrote: 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 RE

Re: Calculate Tape Bytes to Tracks

> >>BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset >>parameters. > > Sometimes? > When is it not? > The resource implications of 'large' block sizes have disappeared, except for > space usage. > There are some old utilities that still require 'strange' block sizes, but I

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

Re: Calcul ate Tape B ytes to Tr acks‏

>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. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access

Re: privilige to run a compress job.

On Sun, May 2, 2010 at 6:07 PM, Paul Gilmartin wrote: > On Sun, 2 May 2010 11:15:12 +0300, Matan Cohen wrote: > > >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 c

Re: Calculate Tape Bytes to Tracks

>IBM says it's 32760. Typo on my part. >BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset >parameters. Sometimes? When is it not? The resource implications of 'large' block sizes have disappeared, except for space usage. There are some old utilities that still require 'st

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

On Sun, 2 May 2010 11:31:41 +0300, 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

Re: privilige to run a compress job.

On Sun, 2 May 2010 11:15:12 +0300, Matan Cohen wrote: >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

Re: Calcul ate Tape B ytes to Tr acks‏

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). John Gilmore, Ashland, MA 01721

Re: 25 reasons why hardware is still hot at IBM

l...@garlic.com (Anne & Lynn Wheeler) writes: > Financial Matters: Mainframe Processor Pricing History > http://www.zjournal.com/index.cfm?section=article&aid=346 > > from above (2006) article: > > is that the price per MIPS today is approximately six times higher than > the $165 per MIPS that the

Re: ADRNAPF was IEBCOP Y losing APF authori sation i n mi ddle of JOB - etc

In , on 04/23/2010 at 07:56 AM, Peter Relson said: >JSCBAUTH: If you turn it off, you almost certainly must *never* turn it >back on again, as you have been giving control to unauthorized code which > could have left things around that could take advantage of this. The TMP turns it back on,

Re: ZFS

In <4bd93060.8000...@bremultibank.com.pl>, on 04/29/2010 at 09:08 AM, "R.S." said: >HFS works without any setup, FSVO works; a big shop will need colony address spaces. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: ZFS

In , on 04/28/2010 at 10:44 PM, Tony Harminc said: >MVT had no system integrity or security at all. Password "security" was >trivially bypassed, Only by those who knew how to get into key 0. If you neglect to protect PASSWORD, that's you fault, not MVT's. >There was no fetch protection for a

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

Re: ZFS

In , on 04/27/2010 at 12:15 PM, Bruce Burgdoff said: >Does this make sense or what are some other ideas to maintain the new zFS > root files? Back before zFS, I used to keep the Unix files completely off of sysres and include the IPL volume serial as part of the dsn, using static system symbo

Re: Calculate Tape Bytes to Tracks

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. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senat

Re: 45 years of Mainframe

In , on 04/26/2010 at 07:47 PM, Tony Harminc said: >Where did the 2301 fit in? The 2301 and 2303 were drums. >but support was dropped in MVS. The drums were not nearly as effective as a fixed-head disk on a block multiplexor channel. However, I believe that Stanford refitted drum support to

Re: Calculate Tape Bytes to Tracks

I am actually using the IBM TAPETOOLS. This was just a quick and dirty process. I like to understand the math before I do the tool. That way I can eye-ball the output and know I have a good result. Lizette > Behalf Of O'Brien, David W. Wrote> > Lizette, > > Have you considered IBM's Volume

Re: 25 reasons why hardware is still hot at IBM

In , on 04/28/2010 at 07:56 AM, Tom Marchant said: >It may reduce training costs, but I'm not persuaded that a "webified" >application increases productivity over a well designed 3270 based >application. Optimist! I'm persuaded that a typical[1] "webified" application reduces productivity

Re: Calculate Tape Bytes to Tracks

>Remember that the maximum blksize on dasd is 27998 ... No. It's not. It's 32765. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the

Re: RACF - Any way to find out before hand what the user's access is to a file

>In those banking environments, did you protect or monitor the use of the LISTDSD, RLIST, or SEARCH commands and their aliases? I wasn't the security admin. I was just aware of the policy and the potential 'exposure'. Considering how obsessive most security personel are, I can assume what was kn

Re: Calculate Tape Bytes to Tracks

Lizette, Have you considered IBM's Volume Mount Analyzer? It's free and you already have it (or as someone is bound to point out, you already have so you're already paying for it.) Point is, it will do what you want at no extra cost. Thank You, Dave O'Brien NIH Contractor _

Re: Calculate Tape Bytes to Tracks

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 n

Re: Calculate Tape Bytes to Tracks

Hi, It should be blksize * blkcount. Remember that the maximum blksize on dasd is 27998, but on tape can be 64K and even larger. This can mean the files will have to be reblocked when copying to dasd. gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua

Calculate Tape Bytes to Tracks

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 bette

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

On Sun, May 2, 2010 at 2:40 PM, Lizette Koehler wrote: > Matan, > > I guess I would need to know more about your environment. > > For windows - what version - windows server 2003 > From mainframe - z/OS V1.?? z\os 1.10 > Do you have other products like NDM, XCOM, etc on Mainframe/Open Systems??? >

Re: 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 tran

Re: RACF - Any way to find out before hand what the user's access is to a file

Ted, In those banking environments, did you protect or monitor the use of the LISTDSD, RLIST, or SEARCH commands and their aliases? As discussed in the October 2009 issue of our RSH RACF Tips newsletter, these commands offer a wealth of information to a would-be hacker, and their use is not logged

Re: RACF password rules

Ulrich, I believe they can cover both 7 and 8 character alphanumeric passwords in a single rule of: SETR PASSWORD( RULE1( LENGTH(7:8) ALPHANUM(1:8))) Regards, Bob - Robert S. Hansel | 2010 RACF Training (January - July) L

Re: RACF - Any way to find out before hand what the user's access is to a file

Gil, For datasets, the ICH408I message and associated SMF type 80 record will show the Generic profile that was guarding the resource at the time of the violation or warning. If they do not specify a profile, it is usually the case that a Discrete profile (one exactly matching the name of the data

Re: privilige to run a compress job.

On Sun, 2 May 2010 12:20:09 +0300 Matan Cohen wrote: :>On Sun, May 2, 2010 at 11:43 AM, Binyamin Dissen > wrote: :>> On Sun, 2 May 2010 11:15:12 +0300 Matan Cohen :>> wrote: :>> :>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 :>> :

Re: privilige to run a compress job.

On Sun, May 2, 2010 at 11:43 AM, Binyamin Dissen wrote: > On Sun, 2 May 2010 11:15:12 +0300 Matan Cohen > wrote: > > :>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. > > Why do you want

Re: privilige to run a compress job.

On Sun, 2 May 2010 11:15:12 +0300 Matan Cohen wrote: :>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. Why do you want him to be able to do that? What is the business case? As he is not addin

Re: privilige to run a compress job.

On Sun, 2 May 2010 11:23:44 +0300 ??? ?? ??? wrote: :>If you give the user READ access to STGADMIN.ADR.STGADMIN.COMPRESS in FACILITY, they will be able to use the COMPRESS command in DFSMSdss to compress libraries. Would that not give him the ability to compress anything, including LINKLIB? Th

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

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

Re: privilige to run a compress job.

Shalom Matan, If you give the user READ access to STGADMIN.ADR.STGADMIN.COMPRESS in FACILITY, they will be able to use the COMPRESS command in DFSMSdss to compress libraries. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Matan Co

privilige to run a compress job.

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