z/OS 1.9 Features summary

[Steve Comstock]

This past month and a half, I've been updating all the
courses I'm responsible for to reflect changes brought
about by z/OS 1.9 in each course's subject area. Since
most folks don't get a chance to explore the new features,
thought I'd list the features introduced in 1.9 that I
think might be of interest to applications programmers.

If you are not an application programmer, you might pass
this on: some of these are very nice to know about. On
the other hand, even if you are not an application
programmer, some of these might be nice to know about.

The usefulness of any particular feature will vary from
person to person, of course; I figure if you see something
that looks helpful to you that you can check the docs
(or, of course, schedule a class!)

Seems like the biggest impacts for this particular
release are in ISPF and the Dialog Manager services.


_TSO, CLIST, REXX, ISPF/Dialog Manager:_

* ISPF: scrollable fields; introduced in 1.5,
enhanced in 1.8 (ZCLRSFLD command), more
widely used in 1.9
[discussed in "ISPF Update"; details covered
in "Developing Dialog Manager Applications
in z/OS"]


* ISPF Edit and View: SOURCE command allows you to
edit and view data in ASCII; LF command lets you
set x'0A's to EBCDIC new lines
[discussed in "Advanced ISPF in z/OS"]


* DSLIST can display total number of tracks in
all datasets in the list
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]


* Two new options on Primary Option Menu:
12 - z/OS System programmer facilities
13 - z/OS application programmer facilities
[all ISPF screen shots of Primary Option Menu
updated]


* Many ISPF data set name entry fields now
support z/OS HFS UNIX files

* Edit and View entry panel
* Edit / View CREATE / REPLACE / COPY / MOVE
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]



* HFS file names and path names can be kept in
personal reference lists)
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]


* ISPF profile can be set so that SAVE does not
clear out the undo buffer; thus, UNDO might be
able to restore data to its condition before
the last SAVE
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]


* The UNIX Directory List Utility (3.17) now uses edit
and browse instead of oedit and obrowse; there is
also a view option now.
[discussed in "ISPF Update" and "Introduction to
z/OS UNIX"]



* Dialog Manager panel language now supports system
symbols in DSNAMEx parameters for VER statement
[discussed in "Developing Dialog Manager Applications
in z/OS"]

* Dialog Manager panel language now supports VSYM builtin
function and VSYM statement to process system symbols
[discussed in "Developing Dialog Manager Applications
in z/OS"]

* Dialog Manager BROWSE, EDIT, and VIEW services now
support z/OS UNIX files
[discussed in "Developing Dialog Manager Applications
in z/OS"]



* Dialog Manager file tailoring adds support for the
&VSYM function to support system symbol resolution
during file tailoring
[discussed in "Developing Dialog Manager Applications
in z/OS"]




_Program Binder_

* Specify -IMMED on REPLACE and CHANGE statements
to make changes apply to target before these
statements instead of after
[discussed in "Secrets of Inter-Language Communication
in z/OS"]


* Binder COMPAT can be specified as ZOSV1R9
[discussed in "Secrets of Inter-Language Communication
in z/OS"]


- several other changes, not related to content of
courses we offer




_Language Environment (LE)_


* CEEDUMP runtime parameter can request CEEDUMP
attributes if CEEDUMP DD statement not supplied
[discussed in "Using LE Services in z/OS"]

* Message tag files may be z/OS UNIX files, the
CEEBLDTX exec has been ported to also run under
the z/OS UNIX shell, and the outputs can be
z/OS UNIX files
[discussed in "Using LE Services in z/OS"]


* HEAPPOOLS runtime parameter can request that cells
in certain heap pools not cross cache line
[discussed in "Using LE Services in z/OS"]


* CEE3DLY callable service - suspends program for
specified number of seconds (up to an hour); can
use under CICS
[discussed in "Using LE Services in z/OS"]


* CEEDLYM callable service - suspends program for
specified number of miiliseconds (up to an hour);
can not use under CICS
[discussed in "Using LE Services in z/OS"]


* CEE3MC2 callable service - returns the currency
symbol for the current country, and the international
currecny symbol for the current country
[discussed in "Using LE Services in z/OS"]


* Point to IBM link to our courses at
http://www-03.ibm.com/servers/eserver/zseries/zos/le/assist/education/trainers.html



* CEEDUMP traceback table format has changed
[discussed in "Using LE Services in z/OS"
and "Enterprise COBOL Debugging and Maintenance"]



_z/OS UNIX System Services_

* Support expanded for version 3 of the Single Unix
Standard, changing the behavior of some commands
such as ed, file, tr
[discussed in "Introduction to z/OS UNIX" and
"Shell Script Programming in z/OS UNIX", as
appropriate]



* Support for new versions of C code: C can be compiled
with the METAL option, which generates C code without
LE linkages; can also support explicit inclusion of
assembler instructions; some z/OS UNIX commands have
options to support this kind of program
- not discussed in our courses, since these features
are intended for the systems programmer; but they
are kinda' cool.-



And, of course, all languages references to Assembler,
COBOL, PL/I, and so on, are current with their release
level.


Do your other course authors keep this current?

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[GAVIN Darren * OPS EAS]

This is good information, being able to work with ASCII files and the
Unix HFS from ISPF directly is a nice change.

Too bad were just now working on the zOS 1.7 Upgrade here.

Darren

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of Steve Comstock
Sent: Monday, October 29, 2007 11:53 AM
To: IBM-***@BAMA.UA.EDU
Subject: z/OS 1.9 Features summary

This past month and a half, I've been updating all the
courses I'm responsible for to reflect changes brought
about by z/OS 1.9 in each course's subject area. Since
most folks don't get a chance to explore the new features,
thought I'd list the features introduced in 1.9 that I
think might be of interest to applications programmers.

If you are not an application programmer, you might pass
this on: some of these are very nice to know about. On
the other hand, even if you are not an application
programmer, some of these might be nice to know about.

The usefulness of any particular feature will vary from
person to person, of course; I figure if you see something
that looks helpful to you that you can check the docs
(or, of course, schedule a class!)

Seems like the biggest impacts for this particular
release are in ISPF and the Dialog Manager services.


_TSO, CLIST, REXX, ISPF/Dialog Manager:_

* ISPF: scrollable fields; introduced in 1.5,
enhanced in 1.8 (ZCLRSFLD command), more
widely used in 1.9
[discussed in "ISPF Update"; details covered
in "Developing Dialog Manager Applications
in z/OS"]


* ISPF Edit and View: SOURCE command allows you to
edit and view data in ASCII; LF command lets you
set x'0A's to EBCDIC new lines
[discussed in "Advanced ISPF in z/OS"]


* DSLIST can display total number of tracks in
all datasets in the list
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]


* Two new options on Primary Option Menu:
12 - z/OS System programmer facilities
13 - z/OS application programmer facilities
[all ISPF screen shots of Primary Option Menu
updated]


* Many ISPF data set name entry fields now
support z/OS HFS UNIX files

* Edit and View entry panel
* Edit / View CREATE / REPLACE / COPY / MOVE
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]



* HFS file names and path names can be kept in
personal reference lists)
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]


* ISPF profile can be set so that SAVE does not
clear out the undo buffer; thus, UNDO might be
able to restore data to its condition before
the last SAVE
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]


* The UNIX Directory List Utility (3.17) now uses edit
and browse instead of oedit and obrowse; there is
also a view option now.
[discussed in "ISPF Update" and "Introduction to
z/OS UNIX"]



* Dialog Manager panel language now supports system
symbols in DSNAMEx parameters for VER statement
[discussed in "Developing Dialog Manager Applications
in z/OS"]

* Dialog Manager panel language now supports VSYM builtin
function and VSYM statement to process system symbols
[discussed in "Developing Dialog Manager Applications
in z/OS"]

* Dialog Manager BROWSE, EDIT, and VIEW services now
support z/OS UNIX files
[discussed in "Developing Dialog Manager Applications
in z/OS"]



* Dialog Manager file tailoring adds support for the
&VSYM function to support system symbol resolution
during file tailoring
[discussed in "Developing Dialog Manager Applications
in z/OS"]




_Program Binder_

* Specify -IMMED on REPLACE and CHANGE statements
to make changes apply to target before these
statements instead of after
[discussed in "Secrets of Inter-Language Communication
in z/OS"]


* Binder COMPAT can be specified as ZOSV1R9
[discussed in "Secrets of Inter-Language Communication
in z/OS"]


- several other changes, not related to content of
courses we offer




_Language Environment (LE)_


* CEEDUMP runtime parameter can request CEEDUMP
attributes if CEEDUMP DD statement not supplied
[discussed in "Using LE Services in z/OS"]

* Message tag files may be z/OS UNIX files, the
CEEBLDTX exec has been ported to also run under
the z/OS UNIX shell, and the outputs can be
z/OS UNIX files
[discussed in "Using LE Services in z/OS"]


* HEAPPOOLS runtime parameter can request that cells
in certain heap pools not cross cache line
[discussed in "Using LE Services in z/OS"]


* CEE3DLY callable service - suspends program for
specified number of seconds (up to an hour); can
use under CICS
[discussed in "Using LE Services in z/OS"]


* CEEDLYM callable service - suspends program for
specified number of miiliseconds (up to an hour);
can not use under CICS
[discussed in "Using LE Services in z/OS"]


* CEE3MC2 callable service - returns the currency
symbol for the current country, and the international
currecny symbol for the current country
[discussed in "Using LE Services in z/OS"]


* Point to IBM link to our courses at
http://www-03.ibm.com/servers/eserver/zseries/zos/le/assist/education/tr
ainers.html



* CEEDUMP traceback table format has changed
[discussed in "Using LE Services in z/OS"
and "Enterprise COBOL Debugging and Maintenance"]



_z/OS UNIX System Services_

* Support expanded for version 3 of the Single Unix
Standard, changing the behavior of some commands
such as ed, file, tr
[discussed in "Introduction to z/OS UNIX" and
"Shell Script Programming in z/OS UNIX", as
appropriate]



* Support for new versions of C code: C can be compiled
with the METAL option, which generates C code without
LE linkages; can also support explicit inclusion of
assembler instructions; some z/OS UNIX commands have
options to support this kind of program
- not discussed in our courses, since these features
are intended for the systems programmer; but they
are kinda' cool.-



And, of course, all languages references to Assembler,
COBOL, PL/I, and so on, are current with their release
level.


Do your other course authors keep this current?

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@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 ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Andy Robertson]

FYI

PASS IT AROUND




Steve Comstock
<***@TRAINERSF To: IBM-***@BAMA.UA.EDU
RIEND.COM> cc: (bcc: Andy Robertson/MANSERV/JLP)
Sent by: IBM Subject: z/OS 1.9 Features summary
Mainframe
Discussion List
<IBM-***@BAMA.U
A.EDU>


29/10/2007 18:52
Please respond
to IBM Mainframe
Discussion List






This past month and a half, I've been updating all the
courses I'm responsible for to reflect changes brought
about by z/OS 1.9 in each course's subject area. Since
most folks don't get a chance to explore the new features,
thought I'd list the features introduced in 1.9 that I
think might be of interest to applications programmers.

If you are not an application programmer, you might pass
this on: some of these are very nice to know about. On
the other hand, even if you are not an application
programmer, some of these might be nice to know about.

The usefulness of any particular feature will vary from
person to person, of course; I figure if you see something
that looks helpful to you that you can check the docs
(or, of course, schedule a class!)

Seems like the biggest impacts for this particular
release are in ISPF and the Dialog Manager services.


_TSO, CLIST, REXX, ISPF/Dialog Manager:_

* ISPF: scrollable fields; introduced in 1.5,
enhanced in 1.8 (ZCLRSFLD command), more
widely used in 1.9
[discussed in "ISPF Update"; details covered
in "Developing Dialog Manager Applications
in z/OS"]


* ISPF Edit and View: SOURCE command allows you to
edit and view data in ASCII; LF command lets you
set x'0A's to EBCDIC new lines
[discussed in "Advanced ISPF in z/OS"]


* DSLIST can display total number of tracks in
all datasets in the list
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]


* Two new options on Primary Option Menu:
12 - z/OS System programmer facilities
13 - z/OS application programmer facilities
[all ISPF screen shots of Primary Option Menu
updated]


* Many ISPF data set name entry fields now
support z/OS HFS UNIX files

* Edit and View entry panel
* Edit / View CREATE / REPLACE / COPY / MOVE
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]



* HFS file names and path names can be kept in
personal reference lists)
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]


* ISPF profile can be set so that SAVE does not
clear out the undo buffer; thus, UNDO might be
able to restore data to its condition before
the last SAVE
[discussed in "TSO/ISPF in z/OS", "ISPF Update",
and in "ISPF and JCL on z/OS"]


* The UNIX Directory List Utility (3.17) now uses edit
and browse instead of oedit and obrowse; there is
also a view option now.
[discussed in "ISPF Update" and "Introduction to
z/OS UNIX"]



* Dialog Manager panel language now supports system
symbols in DSNAMEx parameters for VER statement
[discussed in "Developing Dialog Manager Applications
in z/OS"]

* Dialog Manager panel language now supports VSYM builtin
function and VSYM statement to process system symbols
[discussed in "Developing Dialog Manager Applications
in z/OS"]

* Dialog Manager BROWSE, EDIT, and VIEW services now
support z/OS UNIX files
[discussed in "Developing Dialog Manager Applications
in z/OS"]



* Dialog Manager file tailoring adds support for the
&VSYM function to support system symbol resolution
during file tailoring
[discussed in "Developing Dialog Manager Applications
in z/OS"]




_Program Binder_

* Specify -IMMED on REPLACE and CHANGE statements
to make changes apply to target before these
statements instead of after
[discussed in "Secrets of Inter-Language Communication
in z/OS"]


* Binder COMPAT can be specified as ZOSV1R9
[discussed in "Secrets of Inter-Language Communication
in z/OS"]


- several other changes, not related to content of
courses we offer




_Language Environment (LE)_


* CEEDUMP runtime parameter can request CEEDUMP
attributes if CEEDUMP DD statement not supplied
[discussed in "Using LE Services in z/OS"]

* Message tag files may be z/OS UNIX files, the
CEEBLDTX exec has been ported to also run under
the z/OS UNIX shell, and the outputs can be
z/OS UNIX files
[discussed in "Using LE Services in z/OS"]


* HEAPPOOLS runtime parameter can request that cells
in certain heap pools not cross cache line
[discussed in "Using LE Services in z/OS"]


* CEE3DLY callable service - suspends program for
specified number of seconds (up to an hour); can
use under CICS
[discussed in "Using LE Services in z/OS"]


* CEEDLYM callable service - suspends program for
specified number of miiliseconds (up to an hour);
can not use under CICS
[discussed in "Using LE Services in z/OS"]


* CEE3MC2 callable service - returns the currency
symbol for the current country, and the international
currecny symbol for the current country
[discussed in "Using LE Services in z/OS"]


* Point to IBM link to our courses at
http://www-03.ibm.com/servers/eserver/zseries/zos/le/assist/education/trainers.html




* CEEDUMP traceback table format has changed
[discussed in "Using LE Services in z/OS"
and "Enterprise COBOL Debugging and Maintenance"]



_z/OS UNIX System Services_

* Support expanded for version 3 of the Single Unix
Standard, changing the behavior of some commands
such as ed, file, tr
[discussed in "Introduction to z/OS UNIX" and
"Shell Script Programming in z/OS UNIX", as
appropriate]



* Support for new versions of C code: C can be compiled
with the METAL option, which generates C code without
LE linkages; can also support explicit inclusion of
assembler instructions; some z/OS UNIX commands have
options to support this kind of program
- not discussed in our courses, since these features
are intended for the systems programmer; but they
are kinda' cool.-



And, of course, all languages references to Assembler,
COBOL, PL/I, and so on, are current with their release
level.


Do your other course authors keep this current?

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




**********************************************************************
This email is confidential and may contain copyright material of the John Lewis Partnership. If you are not the intended recipient, please notify us immediately and delete all copies of this message. (Please note that it is your responsibility to scan this message for viruses). Email to and from the John Lewis Partnership is automatically monitored for operational and lawful business reasons.
**********************************************************************
John Lewis plc
Registered in England 233462
Registered office 171 Victoria Street London SW1E 5NN

Websites: http://www.johnlewis.com
http://www.waitrose.com
http://www.greenbee.com
http://www.johnlewispartnership.co.uk

**********************************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ceruti, Gerard G]

Hi All

I am busy researching the possibilities of moving data between 2
Sysplex's primarily for Application folks,
In the current plan only 3590 drives would be shared but in discussion
the option of NFS came up.

Looking further DFS/SMB and NFS both seem to be options.

Has anyone had some experience with both?, are there data size limits
within either ?.

What would be the simplest to mange ?.

Regards
Gerard Ceruti
may the 'z' be with you

__________________________________________________________________________________________________________________________________

Standard Bank Disclaimer and Confidentiality Note

This e-mail, its attachments and any rights attaching hereto are, unless the context clearly indicates otherwise, the property of Standard Bank Group Limited
and/or its subsidiaries ("the Group"). It is confidential, private and intended for the addressee only. Should you not be the addressee and receive this e-mail by
mistake, kindly notify the sender, and delete this e-mail, immediately and do not disclose or use same in any manner whatsoever. Views and opinions
expressed in this e-mail are those of the sender unless clearly stated as those of the Group. The Group accepts no liability whatsoever for any loss or
damages whatsoever and howsoever incurred, or suffered, resulting, or arising, from the use of this email or its attachments. The Group does not warrant the integrity
of this e-mail nor that it is free of errors, viruses, interception or interference. Licensed divisions of the Standard Bank Group are authorised financial services providers
in terms of the Financial Advisory and Intermediary Services Act, No 37 of 2002 (FAIS).
For information about the Standard Bank Group Limited visit our website http://www.standardbank.co.za
___________________________________________________________________________________________________________________________________

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Itschak Mugzach]

You may look at CSM (stands for Cross Sysplex Manager) from
www.Hostsystems.de. The product does many things, like leting a JOB running
on sysplex A to read & write datasets on Sysplex B. It also has an ISPF
OPT3.4 interface to look at catalogs, volume and files of the remote sysplex
(if you are authorized to, of course). I think that you can contact Mr.
Michael Rudolf from HostSystems at ***@hostsystems.de.

Itschak

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ulrich Krueger]

Gerard,
These two sysplexes are physically separate from each other, like two
separate datacenters or two separate customer environments ... correct?
Are these two sysplexes connected via TCP/IP Intranet/Internet? If so, have
you thought about just simply using FTP mainframe to mainframe? Secure, easy
to use (within the limitations/capabilities of FTP, of course).

Alternatively, is there a JES2/NJE connection between the sysplexes? In that
case, TSO TRANSMIT and RECEIVE come to mind as simple, no cost file transfer
methods. Within limits, of course, but suitable for small-fry type simple
transfers.


Regards,
Ulrich Krueger


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf
Of Ceruti, Gerard G
Sent: Tuesday, October 30, 2007 02:09
To: IBM-***@BAMA.UA.EDU
Subject: File sharing between Sysplex's

Hi All

I am busy researching the possibilities of moving data between 2
Sysplex's primarily for Application folks,
In the current plan only 3590 drives would be shared but in discussion
the option of NFS came up.

Looking further DFS/SMB and NFS both seem to be options.

Has anyone had some experience with both?, are there data size limits
within either ?.

What would be the simplest to mange ?.

Regards
Gerard Ceruti
may the 'z' be with you

____________________________________________________________________________
______________________________________________________

Standard Bank Disclaimer and Confidentiality Note

This e-mail, its attachments and any rights attaching hereto are, unless the
context clearly indicates otherwise, the property of Standard Bank Group
Limited
and/or its subsidiaries ("the Group"). It is confidential, private and
intended for the addressee only. Should you not be the addressee and receive
this e-mail by
mistake, kindly notify the sender, and delete this e-mail, immediately and
do not disclose or use same in any manner whatsoever. Views and opinions
expressed in this e-mail are those of the sender unless clearly stated as
those of the Group. The Group accepts no liability whatsoever for any loss
or
damages whatsoever and howsoever incurred, or suffered, resulting, or
arising, from the use of this email or its attachments. The Group does not
warrant the integrity
of this e-mail nor that it is free of errors, viruses, interception or
interference. Licensed divisions of the Standard Bank Group are authorised
financial services providers
in terms of the Financial Advisory and Intermediary Services Act, No 37 of
2002 (FAIS).
For information about the Standard Bank Group Limited visit our website
http://www.standardbank.co.za
____________________________________________________________________________
_______________________________________________________

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@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 ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Itschak Mugzach]

It is possible, but if you want to look for the proper file in the catalog,
you can't do it this way. The idea of CSM is to put the file under a DD card
that point to a SUBSYS=... And ask the partner Sysplex to read the file for
you. It does much more, but it is all described in the manufacture site.


Itschak
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf
Of Ulrich Krueger
Sent: Tuesday, October 30, 2007 6:28 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: File sharing between Sysplex's

Gerard,
These two sysplexes are physically separate from each other, like two
separate datacenters or two separate customer environments ... correct?
Are these two sysplexes connected via TCP/IP Intranet/Internet? If so, have
you thought about just simply using FTP mainframe to mainframe? Secure, easy
to use (within the limitations/capabilities of FTP, of course).

Alternatively, is there a JES2/NJE connection between the sysplexes? In that
case, TSO TRANSMIT and RECEIVE come to mind as simple, no cost file transfer
methods. Within limits, of course, but suitable for small-fry type simple
transfers.


Regards,
Ulrich Krueger


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf
Of Ceruti, Gerard G
Sent: Tuesday, October 30, 2007 02:09
To: IBM-***@BAMA.UA.EDU
Subject: File sharing between Sysplex's

Hi All

I am busy researching the possibilities of moving data between 2 Sysplex's
primarily for Application folks, In the current plan only 3590 drives would
be shared but in discussion the option of NFS came up.

Looking further DFS/SMB and NFS both seem to be options.

Has anyone had some experience with both?, are there data size limits within
either ?.

What would be the simplest to mange ?.

Regards
Gerard Ceruti
may the 'z' be with you

____________________________________________________________________________
______________________________________________________

Standard Bank Disclaimer and Confidentiality Note

This e-mail, its attachments and any rights attaching hereto are, unless the
context clearly indicates otherwise, the property of Standard Bank Group
Limited and/or its subsidiaries ("the Group"). It is confidential, private
and intended for the addressee only. Should you not be the addressee and
receive this e-mail by mistake, kindly notify the sender, and delete this
e-mail, immediately and do not disclose or use same in any manner
whatsoever. Views and opinions expressed in this e-mail are those of the
sender unless clearly stated as those of the Group. The Group accepts no
liability whatsoever for any loss or damages whatsoever and howsoever
incurred, or suffered, resulting, or arising, from the use of this email or
its attachments. The Group does not warrant the integrity of this e-mail nor
that it is free of errors, viruses, interception or interference. Licensed
divisions of the Standard Bank Group are authorised financial services
providers in terms of the Financial Advisory and Intermediary Services Act,
No 37 of
2002 (FAIS).
For information about the Standard Bank Group Limited visit our website
http://www.standardbank.co.za
____________________________________________________________________________
_______________________________________________________

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to ***@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 ***@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 ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Hal Merritt]

Sharing data across a network only works well for very small files and
PC's. So, if you have lots of little files to share between a MF and
PC's, NFS may be an option for you.

Next up is a scheduled, coordinated FTP of selected files. Problem here
is getting updates back to the source files.

The coordinated sharing of data is what database managers do and why
people buy them. This is not a trivial undertaking in many cases.

Good luck

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of Ceruti, Gerard G
Sent: Tuesday, October 30, 2007 4:09 AM
To: IBM-***@BAMA.UA.EDU
Subject: File sharing between Sysplex's

Hi All

I am busy researching the possibilities of moving data between 2
Sysplex's primarily for Application folks,
In the current plan only 3590 drives would be shared but in discussion
the option of NFS came up.

Looking further DFS/SMB and NFS both seem to be options.

Has anyone had some experience with both?, are there data size limits
within either ?.

What would be the simplest to mange ?.

Regards
Gerard Ceruti
may the 'z' be with you


NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[R.S.]

Ceruti, Gerard G wrote:
> Hi All
>
> I am busy researching the possibilities of moving data between 2
> Sysplex's primarily for Application folks,
> In the current plan only 3590 drives would be shared but in discussion
> the option of NFS came up.
>
> Looking further DFS/SMB and NFS both seem to be options.
>
> Has anyone had some experience with both?, are there data size limits
> within either ?.
>
> What would be the simplest to mange ?.

It depends. As usually. <g>
What are your needs ?

If you want simply write data on one sysplex and read it on another,
then shared DASD is IMHO best option. Simplest to establish, least
overhead.

If you want to share HFS files, then I would go to NFS.

DF/SMB ? Well. z/OS can be a server, but I never heard about z/OS as a
SMB client. Did I miss something ?



--
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 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Gould]

On Oct 30, 2007, at 3:10 AM, Andy Robertson wrote:

> FYI
>
> PASS IT AROUND
>
>
>


Steve,

Thanks for distilling the information to a typical joe programmer
level. I sure could have used that when talking with programmers
about testing and what is coming down in a few months. The IBM doc is
(IMO) too high of level. You might want to consider doing a SHARE
session and handing the 1 page out, it would give you higher
visability and possibly more jobs:)

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Steve Comstock]

Andy Robertson wrote:
> FYI
>
> PASS IT AROUND
>

I think you meant to click "Forward" instead of "Reply".


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[John Eells]

Steve Comstock wrote:
<snip>
> * Two new options on Primary Option Menu:
> 12 - z/OS System programmer facilities
> 13 - z/OS application programmer facilities
> [all ISPF screen shots of Primary Option Menu
> updated]
><snip>

If this refers to the panels named ***@390S and ***@390U, they're not
new. Perhaps the ISPF team made the modified ***@PRIM panel with these
selections the default so they always appear now, but the panels
themselves have been around a long time. (I wrote them about 10 years ago.)

Also worthy of note with the Binder, I think (from the z/OS R9 GA
announcement):

"RECFM=U verification is designed to provide the same protection against
writing programs into non-program PDS libraries as is provided for PDSE
libraries. The binder is now designed to write programs only into
libraries having an undefined record format (RECFM=U), to help prevent
changing the DCB attributes of other libraries, unless you specify that
it should do so (for example, by specifying RECFM=U on a DD statement)."

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Steve Comstock]

John Eells wrote:
> Steve Comstock wrote:
> <snip>
>
>> * Two new options on Primary Option Menu:
>> 12 - z/OS System programmer facilities
>> 13 - z/OS application programmer facilities
>> [all ISPF screen shots of Primary Option Menu
>> updated]
>> <snip>
>
>
> If this refers to the panels named ***@390S and ***@390U, they're not
> new. Perhaps the ISPF team made the modified ***@PRIM panel with these
> selections the default so they always appear now, but the panels
> themselves have been around a long time. (I wrote them about 10 years
> ago.)

You're right. The docs say they had been hidden but are
now available by default from the primary option menu.


>
> Also worthy of note with the Binder, I think (from the z/OS R9 GA
> announcement):
>
> "RECFM=U verification is designed to provide the same protection against
> writing programs into non-program PDS libraries as is provided for PDSE
> libraries. The binder is now designed to write programs only into
> libraries having an undefined record format (RECFM=U), to help prevent
> changing the DCB attributes of other libraries, unless you specify that
> it should do so (for example, by specifying RECFM=U on a DD statement)."

I agree that's a great safety valve. (What instructor hasn't seen
his or her students wipe out some libraries?) It didn't make my
list because I considered it a long-overdue feature that won't
change the way applications programmers work. But it is nice to
have. Finally.


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Paul Gilmartin]

On Tue, 30 Oct 2007 07:20:12 -0700, Steve Comstock wrote:

>John Eells wrote:
>>
>> "RECFM=U verification is designed to provide the same protection against
>> writing programs into non-program PDS libraries as is provided for PDSE
>
>I agree that's a great safety valve. (What instructor hasn't seen
>his or her students wipe out some libraries?) It didn't make my
>list because I considered it a long-overdue feature that won't
>change the way applications programmers work. But it is nice to
>have. Finally.
>
Indeed, but too little too late. The OS (not utilities) simply
should _never_ change the attributes of an existing nonempty
data set. (Possible exceptions: increasing BLKSIZE, and for
RECFM=V increasing LRECL.) If need be, the programmer can
allocate a new data set and copy. The only time I've used the
facility is to recover the mess when someone has misused it.
And then I generally wind up with a PDS containing one member
with RECFM=F among others with RECFM=V. The OS (not whatever
utility) should prevented that happening.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Paul Gilmartin
> Sent: Tuesday, October 30, 2007 9:10 AM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: z/OS 1.9 Features summary
>

<snip>

> Indeed, but too little too late. The OS (not utilities) simply
> should _never_ change the attributes of an existing nonempty
> data set. (Possible exceptions: increasing BLKSIZE, and for
> RECFM=V increasing LRECL.) If need be, the programmer can
> allocate a new data set and copy. The only time I've used the
> facility is to recover the mess when someone has misused it.
> And then I generally wind up with a PDS containing one member
> with RECFM=F among others with RECFM=V. The OS (not whatever
> utility) should prevented that happening.
>
> -- gil

I'll go futher than that. The entire concept of LRECL, BLKSIZE, and
RECFM is archaic and should be eliminated. If a program wants to read a
dataset, let it specify what it thinks the LRECL and RECFM should be. If
the system can accomodate that, then so be it - let the system (access
method) read the physical data and present it in the format that the
program wants. The only cavaet is if there is a record which cannot be
processed properly if "reformatted" into the LRECL that the program says
that it can accept.

As an example, suppose I write a program which expects LRECL=80,
RECFM=F. If the actual file only has records which are 80 bytes long or
less, then the access method should just "pad out" the record in my
buffer using some pad character. The pad character could be specified by
the program, or have a specified system default (such as blank or
x'00'). If my program expects RECFM=V and the file is RECFM=F, then give
the program the entire 80 byte record from the file with an appropriate
LLBB file prepended.

I have never truly understood RECFM=U. Why is that superior to RECFM=V
with an appropriate LLBB?

Have I been doing too much UNIX/Linux work lately and been corrupted?

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[h***@cusys.edu]

On 30 Oct 2007 08:22:34 -0700, ***@HEALTHMARKETS.COM (McKown,
John) wrote:

>As an example, suppose I write a program which expects LRECL=80,
>RECFM=F. If the actual file only has records which are 80 bytes long or
>less, then the access method should just "pad out" the record in my
>buffer using some pad character. The pad character could be specified by
>the program, or have a specified system default (such as blank or
>x'00'). If my program expects RECFM=V and the file is RECFM=F, then give
>the program the entire 80 byte record from the file with an appropriate
>LLBB file prepended.

I'd like to either accept this or not depending on whether the
programmer thinks it is acceptable. Record size and format may be
something he wants to check.

But why should a program care about block size?

[GAVIN Darren * OPS EAS]

<snip>
I'll go futher than that. The entire concept of LRECL, BLKSIZE, and
RECFM is archaic and should be eliminated. If a program wants to read a
dataset, let it specify what it thinks the LRECL and RECFM should be. If
the system can accomodate that, then so be it - let the system (access
method) read the physical data and present it in the format that the
program wants. The only cavaet is if there is a record which cannot be
processed properly if "reformatted" into the LRECL that the program says
that it can accept.
</snip>

John,

Actually that can be done already, on FB files one can read in the
entire block into a program, by using the block size as the record
length. However Cobol LE forces DCB matching, so not sure how that gets
turned off to allow for it.

As to the BLKSIZE and LRECL parameters being archaic, they really are
not obsolete.

They are there for efficiency reasons.

Disk I/O is done on physical Blocks, not at the record level, so the
larger the block size the more Efficient I/O is. Each record read is
retrieved directly out of the program's I/O buffer(s) that matches the
Block Size (2 Buffers by default) For even more efficient I/O one can
use BUFNO on the DD to increase the buffering. Usually you want to
enough buffering to hold a size that matches the transfer data package
size of the device the file is on. (Cartridge drives are typically 64K,
Virtual Tape drive 128K, and 3390's are based on their track size (per
model), having enough buffering to return a full cylinder on DASD is a
good way to go or by multiples of full tracks.

Darren

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[h***@cusys.edu]

On 30 Oct 2007 08:47:17 -0700, ***@STATE.OR.US (GAVIN Darren
* OPS EAS) wrote:

>Actually that can be done already, on FB files one can read in the
>entire block into a program, by using the block size as the record
>length. However Cobol LE forces DCB matching, so not sure how that gets
>turned off to allow for it.
>
>As to the BLKSIZE and LRECL parameters being archaic, they really are
>not obsolete.

I love "BLOCK CONTAINS 0" as an attempt to solve this problem.

>They are there for efficiency reasons.

This kind of efficiency should not be in programs nor even jobs
anymore. Switching a file from one disk to another with a different
format should not require any JCL change as the OS picked the best
blocksize at the new location.

[GAVIN Darren * OPS EAS]

Howard,

Yes, I agree, having the BLLSIZE=0 is the way to go now.

However effective use of BUFNO on the DD can really increase
efficiencies when you add enough buffers to match devices transfer
sizes, without going overboard on it.

I've done some tinkering over the past few years and it appears that
128K to 1M of buffering per file seems to cover most devices well. So
you don't always have to change that in the JCL, just find a good value
for BUFNO that applies well to most devices and use the BLKSIZE=0 to get
the max block size for the device.

I will disagree with the statement that efficiencies should not be in
programs or in Jobs. Sometimes it's needed.

Darren



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of Howard Brazee
Sent: Tuesday, October 30, 2007 8:57 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: z/OS 1.9 Features summary

On 30 Oct 2007 08:47:17 -0700, ***@STATE.OR.US (GAVIN Darren
* OPS EAS) wrote:

>Actually that can be done already, on FB files one can read in the
>entire block into a program, by using the block size as the record
>length. However Cobol LE forces DCB matching, so not sure how that
gets
>turned off to allow for it.
>
>As to the BLKSIZE and LRECL parameters being archaic, they really are
>not obsolete.

I love "BLOCK CONTAINS 0" as an attempt to solve this problem.

>They are there for efficiency reasons.

This kind of efficiency should not be in programs nor even jobs
anymore. Switching a file from one disk to another with a different
format should not require any JCL change as the OS picked the best
blocksize at the new location.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@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 ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Clark Morris]

On 30 Oct 2007 09:18:04 -0700, in bit.listserv.ibm-main you wrote:

>Howard,
>
>Yes, I agree, having the BLLSIZE=0 is the way to go now.

Of course IBM should provide a compile option to default to BLOCK = 0
in the FD statement for COBOL. This is permissible within the COBOL
standard, both 1985 and 2002. We should not have to code it.
>
>However effective use of BUFNO on the DD can really increase
>efficiencies when you add enough buffers to match devices transfer
>sizes, without going overboard on it.
>
>I've done some tinkering over the past few years and it appears that
>128K to 1M of buffering per file seems to cover most devices well. So
>you don't always have to change that in the JCL, just find a good value
>for BUFNO that applies well to most devices and use the BLKSIZE=0 to get
>the max block size for the device.
>
>I will disagree with the statement that efficiencies should not be in
>programs or in Jobs. Sometimes it's needed.
>
>Darren
>
>> rest snipped

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Gould]

On Nov 3, 2007, at 8:05 PM, Clark Morris wrote:

> On 30 Oct 2007 09:18:04 -0700, in bit.listserv.ibm-main you wrote:
>
>> Howard,
>>
>> Yes, I agree, having the BLLSIZE=0 is the way to go now.
>
> Of course IBM should provide a compile option to default to BLOCK = 0
> in the FD statement for COBOL. This is permissible within the COBOL
> standard, both 1985 and 2002. We should not have to code it.
------------------SNIP---------

Clark,

You bring up an interesting point. One unfortunately there is
probably no good answer for (at least that will make everyone happy).
I sort of agree with you but I can definitely see where some
companies would not agree to. None the less it would probably be
worth writing up a SHARE requirement for. I would also be interested
to hear how IBM would respond to it (other than a FO). I have not
been part of the requirement process in quite some time, but the last
I was in the loop was that IBM was rather err loose in responding to
requirements. Most of the times that I saw IBM would give a non
answer (to anything but accepted). I guess that is their right but
(to me) it left the audience guessing if IBM really agreed with it or
if they will bury it. I vaguely remember that (when GUIDE submitted
requirements) it was floated around IBM and it usually got to the
right people when they wanted to respond but most of the time it went
into the holding pen in the sky when they didn't want to.

I would think that there would be a rather spirited discussion in the
COBOL Group about the requirement.

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gerhard Adam]

> As to the BLKSIZE and LRECL parameters being archaic, they really are
> not obsolete.
>
> They are there for efficiency reasons.
>
> Disk I/O is done on physical Blocks, not at the record level, so the
> larger the block size the more Efficient I/O is. Each record read is
> retrieved directly out of the program's I/O buffer(s) that matches the
> Block Size (2 Buffers by default) For even more efficient I/O one can
> use BUFNO on the DD to increase the buffering. Usually you want to
> enough buffering to hold a size that matches the transfer data package
> size of the device the file is on. (Cartridge drives are typically 64K,
> Virtual Tape drive 128K, and 3390's are based on their track size (per
> model), having enough buffering to return a full cylinder on DASD is a
> good way to go or by multiples of full tracks.

I beg to differ. All the points that are being raised are indicative of
knowing what the underlying device geometry actually is, to try and gain
efficiency from I/O operations. In truth, the physical geometry is largely
unknown and most of the data is actually returned from some level of cache,
where blocksizes mean nothing (since gaps don't exist). A programmer only
needs to specify the LRECL and RECFM (which exist as stand-alone parms), so
I don't understand why BLKSIZE is even discussed unless people simply aren't
using the existing facilities.

BTW. IIRC, the default buffer number is 5 for sequential files.

Adam

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[GAVIN Darren * OPS EAS]

I beg to differ right back, the default buffering is 2, according to the
IBM Manuals. Your shop might have changed that through SMS. Some places
do that.

<Snip>In truth, the physical geometry is largely
Unknown and most of the data is actually returned from some level of
cache,
where blocksizes mean nothing (since gaps don't exist).</Snip>

And I will differ with you on this point as well, as I've done my own
testing of Buffering sizes based on Data Transfer Sizes (that are
readily available in the manuals) and that matching them is the most
efficient way to do I/O. Once the Data leaves the cache of the devices,
it is transferred at a certain size/rate. Matching that size with
additional buffers means that less actual I/O requests are made to the
channel.

Darren


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of Gerhard Adam
Sent: Tuesday, October 30, 2007 6:12 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: z/OS 1.9 Features summary

> As to the BLKSIZE and LRECL parameters being archaic, they really are
> not obsolete.
>
> They are there for efficiency reasons.
>
> Disk I/O is done on physical Blocks, not at the record level, so the
> larger the block size the more Efficient I/O is. Each record read is
> retrieved directly out of the program's I/O buffer(s) that matches the
> Block Size (2 Buffers by default) For even more efficient I/O one can
> use BUFNO on the DD to increase the buffering. Usually you want to
> enough buffering to hold a size that matches the transfer data package
> size of the device the file is on. (Cartridge drives are typically
64K,
> Virtual Tape drive 128K, and 3390's are based on their track size (per
> model), having enough buffering to return a full cylinder on DASD is a
> good way to go or by multiples of full tracks.

I beg to differ. All the points that are being raised are indicative of

knowing what the underlying device geometry actually is, to try and gain

efficiency from I/O operations. In truth, the physical geometry is
largely
unknown and most of the data is actually returned from some level of
cache,
where blocksizes mean nothing (since gaps don't exist). A programmer
only
needs to specify the LRECL and RECFM (which exist as stand-alone parms),
so
I don't understand why BLKSIZE is even discussed unless people simply
aren't
using the existing facilities.

BTW. IIRC, the default buffer number is 5 for sequential files.

Adam

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@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 ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Steve Comstock]

GAVIN Darren * OPS EAS wrote:
> I beg to differ right back, the default buffering is 2, according to the
> IBM Manuals. Your shop might have changed that through SMS. Some places
> do that.

Hmmm. Which manuals? Here are some excerpts:

JCL Ref.:

under DD DATA it says, in part:

"JES3 will honor the BUFNO specification for
SYSIN data sets. Values between 0 and 255
are accepted. When 0 or 1 is specified, a
default of 2 is used."



under DD DCB it says, in part:

"If the DCB BUFNO subparameter is not specified
in the program, five buffers are assigned."


I was astounded to see that BUFNO is not listed as a
standalone DD statement parameter, like most of the
DCB parameters have been for many years! I know I've
used BUFNO= on DD statements without the DCB parm
itself. Wonder why it's not documented as such?



Using Data Sets:

Under "Constructing a Buffer Pool Automatically":

"For QSAM, BUFNO can be specified or permitted to
default in the following ways:

* n — Extended format but not compressed format and
not LBI (n = 2 × blocks per track × number of
stripes)

* 1 — Compressed format data set, PDSE, SYSIN, SYSOUT,
SUBSYS, UNIX files

* 2 — Block size > =32 760 3—2540 Card Reader or Punch

* 5 — All others"



Macros for Data Sets:

For DCB for BDAM:

"If dynamic buffering is requested when an existing
direct data set is being processed, BUFNO is optional;
if omitted, the system acquires two buffers."


For DCB for BPAM:

"The default value is zero." for BUFNO



For DCB for BSAM:

"The default value is zero." for BUFNO



For DCB for QSAM:

"If BUFNO is omitted and the buffers are
acquired automatically, the system acquires:

* 1 for a PDSE member
* 1 for an extended format data set in compressed format
* 1 for a UNIX file
* (2 * number of stripes * number of blocks per track)
for an extended format data set if it is not in the
compressed format
* 2 if the block size is greater than or equal to 32768
* 3 for an IBM 2540 card reader or card punch
* 5 for other types of devices or data sets"


New in z/OS 1.9, if you use a DCBE and code MULTDSN=,
the system uses an alternate methodology to compute
the number of buffers to allocate


>
> <Snip>In truth, the physical geometry is largely
> Unknown and most of the data is actually returned from some level of
> cache,
> where blocksizes mean nothing (since gaps don't exist).</Snip>
>
> And I will differ with you on this point as well, as I've done my own
> testing of Buffering sizes based on Data Transfer Sizes (that are
> readily available in the manuals) and that matching them is the most
> efficient way to do I/O. Once the Data leaves the cache of the devices,
> it is transferred at a certain size/rate. Matching that size with
> additional buffers means that less actual I/O requests are made to the
> channel.
>
> Darren
>
>
> -----Original Message-----

>
>>As to the BLKSIZE and LRECL parameters being archaic, they really are
>>not obsolete.
>>
>>They are there for efficiency reasons.
>>
>>Disk I/O is done on physical Blocks, not at the record level, so the
>>larger the block size the more Efficient I/O is. Each record read is
>>retrieved directly out of the program's I/O buffer(s) that matches the
>>Block Size (2 Buffers by default) For even more efficient I/O one can
>>use BUFNO on the DD to increase the buffering. Usually you want to
>>enough buffering to hold a size that matches the transfer data package
>>size of the device the file is on. (Cartridge drives are typically
>
> 64K,
>
>>Virtual Tape drive 128K, and 3390's are based on their track size (per
>>model), having enough buffering to return a full cylinder on DASD is a
>>good way to go or by multiples of full tracks.
>
>
> I beg to differ. All the points that are being raised are indicative of
>
> knowing what the underlying device geometry actually is, to try and gain
>
> efficiency from I/O operations. In truth, the physical geometry is
> largely
> unknown and most of the data is actually returned from some level of
> cache,
> where blocksizes mean nothing (since gaps don't exist). A programmer
> only
> needs to specify the LRECL and RECFM (which exist as stand-alone parms),
> so
> I don't understand why BLKSIZE is even discussed unless people simply
> aren't
> using the existing facilities.
>
> BTW. IIRC, the default buffer number is 5 for sequential files.
>
> Adam


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Gould]

On Oct 31, 2007, at 10:24 AM, GAVIN Darren * OPS EAS wrote:

> I beg to differ right back, the default buffering is 2, according
> to the
> IBM Manuals. Your shop might have changed that through SMS. Some
> places
> do that.
>
> <Snip>In truth, the physical geometry is largely
> Unknown and most of the data is actually returned from some level of
> cache,
> where blocksizes mean nothing (since gaps don't exist).</Snip>
>
> And I will differ with you on this point as well, as I've done my own
> testing of Buffering sizes based on Data Transfer Sizes (that are
> readily available in the manuals) and that matching them is the most
> efficient way to do I/O. Once the Data leaves the cache of the
> devices,
> it is transferred at a certain size/rate. Matching that size with
> additional buffers means that less actual I/O requests are made to the
> channel.
>
> Darren
>


IBM made the default for QSAM data sets (20 or so years ago) to 5 and
the default is for chained scheduling (for QSAM ) at the same time.
This was accomplished by integrating SAMe into DFSMS.

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[GAVIN Darren * OPS EAS]

Good information all,

I was basing it off the JCL manual.

I rarely get a chance to dig through the DS Macros, or DFHSMS Manuals,
or some of the other more technical manuals, which is why I never caught
that change.

However it still is a good idea to try to match buffering to today's LBI
devices. (64K for Cart, 128K for Tape Silo's, and I -think- DASD after
3390-09's transfers at 256K LBI) It gives the speed advantage of LBI
usage without having to try and use the LBI interface directly from
programs. (I'll admit I never tried using LBI directly at all, as
adequate buffering based on the LBI (Transfer) size seems to accomplish
the same thing)

Not arguing that it would make sense if SMS or the OS could be enhanced
to default buffering for a file based on the LBI of its device.

Which begs another question; is there any storage devices left on
mainframes that are not LBI?

Darren





-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of Ed Gould
Sent: Wednesday, October 31, 2007 11:00 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: z/OS 1.9 Features summary

On Oct 31, 2007, at 10:24 AM, GAVIN Darren * OPS EAS wrote:

> I beg to differ right back, the default buffering is 2, according
> to the
> IBM Manuals. Your shop might have changed that through SMS. Some
> places
> do that.
>
> <Snip>In truth, the physical geometry is largely
> Unknown and most of the data is actually returned from some level of
> cache,
> where blocksizes mean nothing (since gaps don't exist).</Snip>
>
> And I will differ with you on this point as well, as I've done my own
> testing of Buffering sizes based on Data Transfer Sizes (that are
> readily available in the manuals) and that matching them is the most
> efficient way to do I/O. Once the Data leaves the cache of the
> devices,
> it is transferred at a certain size/rate. Matching that size with
> additional buffers means that less actual I/O requests are made to the
> channel.
>
> Darren
>


IBM made the default for QSAM data sets (20 or so years ago) to 5 and
the default is for chained scheduling (for QSAM ) at the same time.
This was accomplished by integrating SAMe into DFSMS.

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@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 ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Rick Fochtman]

----------------------------------<snip>-------------------
Indeed, but too little too late. The OS (not utilities) simplyshould
_never_ change the attributes of an existing nonempty data set.
(Possible exceptions: increasing BLKSIZE, and for RECFM=V increasing
LRECL.) If need be, the programmer can allocate a new data set and copy.
The only time I've used the facility is to recover the mess when someone
has misused it. And then I generally wind up with a PDS containing one
member with RECFM=F among others with RECFM=V. The OS (not whatever
utility) should prevented that happening.
------------------------------<unsnip>----------------------
I disagree strongly. While there are tools that will change dataset
attributes without the use of the OS facilities, the proper solution to
the types of problems you describe is EDUCATION of programmers and the
writers of JCL.

My two cents worth.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Rick Fochtman
> Sent: Tuesday, October 30, 2007 12:58 PM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: z/OS 1.9 Features summary
>
>
> ----------------------------------<snip>-------------------
> Indeed, but too little too late. The OS (not utilities) simplyshould
> _never_ change the attributes of an existing nonempty data set.
> (Possible exceptions: increasing BLKSIZE, and for RECFM=V increasing
> LRECL.) If need be, the programmer can allocate a new data
> set and copy.
> The only time I've used the facility is to recover the mess
> when someone
> has misused it. And then I generally wind up with a PDS
> containing one
> member with RECFM=F among others with RECFM=V. The OS (not whatever
> utility) should prevented that happening.
> ------------------------------<unsnip>----------------------
> I disagree strongly. While there are tools that will change dataset
> attributes without the use of the OS facilities, the proper
> solution to
> the types of problems you describe is EDUCATION of
> programmers and the
> writers of JCL.
>
> My two cents worth.

Though in the past I would agree with you, I no longer do. I've
graduated to a XXXXL clue stick for the programming staff with NO
RESULTS. The current crop seem to have the attitude of "it should work
the way that I think it should work and want it to work. I don't have
time to be bothered. I'm too busy as it is." I blame the Web and MS for
this "instant gratification" desire in IT and end-users.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gerhard Adam]

> Though in the past I would agree with you, I no longer do. I've
> graduated to a XXXXL clue stick for the programming staff with NO
> RESULTS. The current crop seem to have the attitude of "it should work
> the way that I think it should work and want it to work. I don't have
> time to be bothered. I'm too busy as it is." I blame the Web and MS for
> this "instant gratification" desire in IT and end-users.

Perhaps we should stop calling them programmers and considering them
technical? Maybe I'm being a bit too harsh, but perhaps part of the problem
is that we still insist on giving people technical titles and
responsibilities (from decades where they actually meant something) to
people that are, at best, administrators.

I realize that there have always been problem individuals, or people with
fewer that the desired skills. But, in truth, I have never heard more
whining from people that have access to the best tools and technology
available, yet they can't seem to figure out how to code an IEBGENER job
stream. Even worse, there has never been more documentation available than
there is today, yet the average "programmer" doesn't seem to realize that
(just like books), PDFs don't read themselves. In the past many people were
accused of only copying the examples from manuals rather than reading them,
yet in many ways I wish the current crop would be even that industrious.

I also recognize that there are exceptions to this rant out there and to
them I apologize for my statements and wish them much luck.

My two cents

Adam

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Gerhard Adam
> Sent: Tuesday, October 30, 2007 8:57 PM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: z/OS 1.9 Features summary
>
>
> > Though in the past I would agree with you, I no longer do. I've
> > graduated to a XXXXL clue stick for the programming staff with NO
> > RESULTS. The current crop seem to have the attitude of "it
> should work
> > the way that I think it should work and want it to work. I
> don't have
> > time to be bothered. I'm too busy as it is." I blame the
> Web and MS for
> > this "instant gratification" desire in IT and end-users.
>
> Perhaps we should stop calling them programmers and considering them
> technical? Maybe I'm being a bit too harsh, but perhaps part
> of the problem
> is that we still insist on giving people technical titles and
> responsibilities (from decades where they actually meant
> something) to
> people that are, at best, administrators.

Yes - and the worst ones are the ones who also insist on being called
"Software Engineer". The word Engineer is in my title as well. I never
use it. I'm a sysprog, damn it!

>
> I realize that there have always been problem individuals, or
> people with
> fewer that the desired skills. But, in truth, I have never
> heard more
> whining from people that have access to the best tools and technology
> available, yet they can't seem to figure out how to code an
> IEBGENER job
> stream. Even worse, there has never been more documentation
> available than
> there is today, yet the average "programmer" doesn't seem to
> realize that
> (just like books), PDFs don't read themselves. In the past
> many people were
> accused of only copying the examples from manuals rather than
> reading them,
> yet in many ways I wish the current crop would be even that
> industrious.

Or as I overhead my boss on the phone with level 1 support for some
product. They wanted an IEBGENER unload of a load library. When the boss
asked "Don't you mean IEBCOPY?", then insisted that they meant IEBGENER!

>
> I also recognize that there are exceptions to this rant out
> there and to
> them I apologize for my statements and wish them much luck.

True. We a couple of "old tyme" programmers who are good. They are
usually swamped because they can actually get the job done.

>
> My two cents
>
> Adam



--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[h***@cusys.edu]

On 31 Oct 2007 05:52:47 -0700, ***@HEALTHMARKETS.COM (McKown,
John) wrote:

>Yes - and the worst ones are the ones who also insist on being called
>"Software Engineer". The word Engineer is in my title as well. I never
>use it. I'm a sysprog, damn it!

I once worked for EDS when I was given that title. I found that the
utility in that title was that it obscured my function and rank -
which is useful when I was working in some other company's shop where
titles were more defined - and where titles could interfere with my
authority and ability to do the job.

[Paul Gilmartin]

On Tue, 30 Oct 2007 10:19:46 -0500, McKown, John wrote:
>
>> Indeed, but too little too late. The OS (not utilities) simply
>> should _never_ change the attributes of an existing nonempty
>> data set. ...
>
>I'll go futher than that. The entire concept of LRECL, BLKSIZE, and
>RECFM is archaic and should be eliminated. If a program wants to read aQ
>dataset, let it specify what it thinks the LRECL and RECFM should be. If
>the system can accomodate that, then so be it - let the system (access
>method) read the physical data and present it in the format that the
>
Quite as the BSAM/QSAM interface to HFS/NFS/ZFS operates. The
implementors of that facility were clever. Much the same for
PDSE wrt BLKSIZE, though not LRECL nor RECFM.

Wouldn't it be nice to have RECFM=STREAM,LINEND=NL, in addition?
(Would probably work best on FBA DASD.)

>program wants. The only cavaet is if there is a record which cannot be
>processed properly if "reformatted" into the LRECL that the program says
>that it can accept.
>
UNIX FS interface gives I/O error: "READ WRONG LENGTH RECORD" for this.

At its glacial pace, IBM is accommodating twentieth century technology.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Arthur T.]

On 30 Oct 2007 08:47:17 -0700, in bit.listserv.ibm-main
(Message-ID:<***@exchnode02.ad.state.or.us>)
***@STATE.OR.US (GAVIN Darren * OPS EAS) wrote:

><snip>
>I'll go futher than that. The entire concept of LRECL,
>BLKSIZE, and
>RECFM is archaic and should be eliminated. If a program
>wants to read a
>dataset, let it specify what it thinks the LRECL and RECFM
>should be. If
>the system can accomodate that, then so be it - let the
>system (access
>method) read the physical data and present it in the
>format that the
>program wants. The only cavaet is if there is a record
>which cannot be
>processed properly if "reformatted" into the LRECL that
>the program says
>that it can accept.
></snip>
>
>John,
<snip>


>As to the BLKSIZE and LRECL parameters being archaic, they
>really are
>not obsolete.
>
>They are there for efficiency reasons.

I think a compromise between current usage and what
John suggested would be very useful.

Say that a new application requires you to add fields
to a file's records. You add them at the end. Why should
you have to recompile all of the programs which don't use
those fields? Let the access method ignore the rest of the
record when used for input. Thus, only programs which use
the new fields and those that write to the file would need
updating.


--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gerhard Adam]

> Say that a new application requires you to add fields
> to a file's records. You add them at the end. Why should you have to
> recompile all of the programs which don't use those fields? Let the
> access method ignore the rest of the record when used for input. Thus,
> only programs which use the new fields and those that write to the file
> would need updating.
>

Sorry, but this simply seems quaint. What happens when a field increases in
size, not at the end? Why should we have separate implementations for
applications programs, but system utilities can't utilize this function?
The later point being that an incorrect LRECL specification on an IEBGENER
or SORT could be disastrous.

If the intent is to provide a character-based file management structure like
PCs then that is certainly possible, with all the attendant overhead of
doing so. A record-based management scheme requires that the application
take some responsibility for designating what constitutes a record. Instead
of making the access method responsible for truncating data arbitrarily
based on LRECL, how about we consider designing applications with some
growth built into them with reserved fields? The only reason programs need
to be re-compiled when fields are added is because the original applications
people never planned for any changes, and personally I don't think such poor
practices become the fault of the operating system to correct.

Adam

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>At its glacial pace, IBM is accommodating twentieth century technology.

Can you do something other than complain?

IBM is trying the 'revolution in an evolutionary manner'.

I, for one, would not want to have to re-compile everything whenever a new version/release comes along!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Gould]

On Oct 30, 2007, at 1:05 PM, Ted MacNEIL wrote:

>> At its glacial pace, IBM is accommodating twentieth century
>> technology.
>
> Can you do something other than complain?
>
> IBM is trying the 'revolution in an evolutionary manner'.
>
> I, for one, would not want to have to re-compile everything
> whenever a new version/release comes along!
>


Ted,

I would like to disagree with you a little.

If we had to recompile then all those programs that got lost (Y2K
ring a bell?) probably wouldn't have. To this day we still have
people trying to translate load to source (usually COBOL but plug in
almost any language).

I agree its a PITA to recompile but there some (good?) reasons to do so.

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Kopischke]

On Tue, 30 Oct 2007 09:46:36 -0600, Howard Brazee wrote:

>
>But why should a program care about block size?
>

Funny you should ask this; We had a major project implement a couple weeks
ago. To deal with the number of object moves, many of the libraries were just
cloned and renamed at implementation time. During this, a couple pretty
important PDS's were reblocked. A pretty benign change from my point of view.

It turns out a program update process allocates one of these PDS's
SHR,BLKSIZE=3200. This effectively reblocked the PDS. Every member in this
PDS that was longer than about 40 lines was corrupted and innaccessible.

That's a reason to care, but probably not the point trying to be made. There
are code bombs waiting to explode. Even a seemingly benign change can
trigger one.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Howard Brazee]

On 30 Oct 2007 11:30:25 -0700, in bit.listserv.ibm-main you wrote:

>>But why should a program care about block size?
>>
>
>Funny you should ask this; We had a major project implement a couple weeks
>ago. To deal with the number of object moves, many of the libraries were just
>cloned and renamed at implementation time. During this, a couple pretty
>important PDS's were reblocked. A pretty benign change from my point of view.
>
>It turns out a program update process allocates one of these PDS's
>SHR,BLKSIZE=3200. This effectively reblocked the PDS. Every member in this
>PDS that was longer than about 40 lines was corrupted and innaccessible.
>
>That's a reason to care, but probably not the point trying to be made. There
>are code bombs waiting to explode. Even a seemingly benign change can
>trigger one.

It is absolutely a reason to care - and to demand that the Operating
System do the work.

It's like having Java do housekeeping - in today's society memory
leaks cost more than the overhead of having the system do the work.

And we also find it cost effective to put privilege checks into the
database instead of the programs.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Kopischke]

On Tue, 30 Oct 2007 12:56:45 -0600, Howard Brazee wrote:

>On 30 Oct 2007 11:30:25 -0700, in bit.listserv.ibm-main you wrote:
>
>>>But why should a program care about block size?
>>>
>>
>>Funny you should ask this; We had a major project implement a couple
weeks
>>ago. To deal with the number of object moves, many of the libraries were
just
>>cloned and renamed at implementation time. During this, a couple pretty
>>important PDS's were reblocked. A pretty benign change from my point of
view.
>>
>>It turns out a program update process allocates one of these PDS's
>>SHR,BLKSIZE=3200. This effectively reblocked the PDS. Every member in this
>>PDS that was longer than about 40 lines was corrupted and innaccessible.
>>
>>That's a reason to care, but probably not the point trying to be made. There
>>are code bombs waiting to explode. Even a seemingly benign change can
>>trigger one.
>
>It is absolutely a reason to care - and to demand that the Operating
>System do the work.
>

I guess I would counter that coding omnipotence into the OS would be
expensive from a performance standpoint, it would be a moving target and it's
probably not even possible. As things evolve, what was once common practice
is no longer.

Who would have guessed that something like this would be waiting to cause a
problem ??? If you were coding the OS, would you have thought of this
one ??? I still don't understand why it was there in the first place.

LE seems to want to do a lot of this cross checking stuff, but I'm not so sure I
want to be blocked from doing something. Correcting the issue without data
loss relied on this functioning equally irrationally both ways - corrupting it with
a program and fixing it with a utility. If the utility had been so smart as to
block the correction, I would have been recovering this PDS from a backup,
losing a lot of updates and hoping I found the problem so the updates could be
reapplied.

I think this thread tangent concerns fundamental changes in the OS that may
uncover some of these issues. I think I'd rather partake in a glacial evolution
rather than wholesale change that might frighten users, substantially increase
maintenance costs and encourage a migration away from the platform.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Patrick O'Keefe]

On Tue, 30 Oct 2007 09:06:07 -0400, John Eells <***@US.IBM.COM>
wrote:

>...
>The binder is now designed to write programs only into
>libraries having an undefined record format (RECFM=U), to help
>prevent changing the DCB attributes of other libraries, unless you
>specify that it should do so (for example, by specifying RECFM=U
>on a DD statement)."
>...

What a very peculiar exception. I understand that it was probably
easier to accept the overriding DD parm than to check for it and
reject it, but this sounds dangerous. If I know at the time I'm
building JCL that I want to change the characteristics of the
dataset, why would I wait for the BINDER to do it for me?

Murphy's law dictates that if that override gets put in any BINDER
JCL, THAT job is the one that will be cloned by all the neophytes
needing BINDER JCL; the feature will be effectively disabled.

Pat O'Keefe

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Paul Gilmartin]

On Tue, 30 Oct 2007 18:05:02 +0000, Ted MacNEIL wrote:

>>At its glacial pace, IBM is accommodating twentieth century technology.
>
>Can you do something other than complain?
>
Didn't I say it was improving?

>IBM is trying the 'revolution in an evolutionary manner'.
>
And in the text you snipped, I pointed out to John M. that
the newest facilities are significantly better; even very
close to what John experssed a wish for.

>I, for one, would not want to have to re-compile everything whenever a new version/release comes along!
>
And I, for one, don't want even to change JCL whenever a new
storage device comes along. SDB is a step in the right
direction. But it's resisted by the stickshift mentality:
the driver who can choose his shift points better than any
automatic transmission and the programmer who can choose a
block size more optimal than any automated system. Phil
Payne and Darren Gavin likely are (or at least consider
themselves) respective examples. I can't do either, or at
least my time isn't worth it. Automatic transmissions and
SDB remove distractions and let the driver and the programmer
concentrate on the genuine task.

But SDB came too late: if it had been present in rudimentary
form, supplying a valid but nonoptimal BLKSIZE, in OS/360
release 1, coding BLKSIZE could always have been optional,
and much of the rough transition to present techniques could
have been avoided.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gerhard Adam]

> But SDB came too late: if it had been present in rudimentary
> form, supplying a valid but nonoptimal BLKSIZE, in OS/360
> release 1, coding BLKSIZE could always have been optional,
> and much of the rough transition to present techniques could
> have been avoided.

Boy are you dreaming. Maybe you don't recall, but even with Virtual Storage
Constraint (VSC), and system programmers evaluating which modules could be
eliminated from processor storage (LPA) so that demands could be met in CSA
or Private ... The use of blocksizes for programs, early buffer pools (ie.
VSAM files, esp with multiple strings) were quite significant and the last
thing I would have wanted was an operating system making arbitrary decisions
about what was consider "optimal". Maybe it was optimal for I/O, but it
could've killed many a paging subsystem with excessive storage demand.
Given the problems and constraints that had to be dealt with in early
systems, I seriously doubt that SDB was at the top of anyone's list of
issues that needed to addressed as a priority item.

As for "rough transitions", I have to wonder whether people that can't get
BLKSIZE and LRECL straight in their minds are in any position to be
designing or developing anything. This is some of the most trivial of the
trivial problems associated with data management. This mentality of having
the operating system do it, is precisely why people overload systems and
wonder why throughput suffers, or why DBA's turn on every trace under the
sun and wonder at the attendant overhead in database performance.

Like it or not, this is a technical field and such a trivial problem
shouldn't even be fodder for discussion.

Adam

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Gould]

On Oct 30, 2007, at 9:22 PM, Gerhard Adam wrote:

>> But SDB came too late: if it had been present in rudimentary
>> form, supplying a valid but nonoptimal BLKSIZE, in OS/360
>> release 1, coding BLKSIZE could always have been optional,
>> and much of the rough transition to present techniques could
>> have been avoided.
>
> Boy are you dreaming. Maybe you don't recall, but even with
> Virtual Storage Constraint (VSC), and system programmers evaluating
> which modules could be eliminated from processor storage (LPA) so
> that demands could be met in CSA or Private ... The use of
> blocksizes for programs, early buffer pools (ie. VSAM files, esp
> with multiple strings) were quite significant and the last thing I
> would have wanted was an operating system making arbitrary
> decisions about what was consider "optimal". Maybe it was optimal
> for I/O, but it could've killed many a paging subsystem with
> excessive storage demand. Given the problems and constraints that
> had to be dealt with in early systems, I seriously doubt that SDB
> was at the top of anyone's list of issues that needed to addressed
> as a priority item.

I think I would like to suggest that maybe the list as you put it has
pretty much been there since day 1 of OS/360 (before Virtual
Storage). As an example we had a IBM SE (yes a real SE) worked up a
document (that was later published as an orange book) showing optimal
blocksizes on tape AND buffering the tape and how it would benefit
the company ie reduced run time faster sorts ect. I believe that his
document started development on IBM's SAMe (the cost option to make
it as a default to do changed scheduling and the default buffno to 5.
We were amoung the first to buy and install the product (we had the
black and blue marks to prove it). Yes it was rough (although some
had worse experiences than we) but we stuck at it and got a real
benefit from it. It wasn't IBM's most shinning moment but we got real
value from it and to this day the people that have benefited from
this product (now included in DFSMS) is real. For an example we went
from 10 hour processing our nightly batch window to half that amount.
Yes we needed more storage but the cut in run time saved us from
buying a larger machine at the time (btw this was at a different
company). So this did help out at many other companies. No JCL DD
changes, it installed and it worked.


>
> As for "rough transitions", I have to wonder whether people that
> can't get BLKSIZE and LRECL straight in their minds are in any
> position to be designing or developing anything. This is some of
> the most trivial of the trivial problems associated with data
> management. This mentality of having the operating system do it,
> is precisely why people overload systems and wonder why throughput
> suffers, or why DBA's turn on every trace under the sun and wonder
> at the attendant overhead in database performance.

I am neutral on this issue as the issues you site are somewhat true
but they are somewhat false. SHould it be transparent... I am really
mixed. I have seen (somewhat) the PC side and it leads to sloppy
programming and frequently unpredictable results. Not taking sides
too much I would rather have predictable results.
>
> Like it or not, this is a technical field and such a trivial
> problem shouldn't even be fodder for discussion.

I don't agree there is almost always room for discussion and when
there is each side has room for movement. One key issue that I think
you have to give a stance to is predictability. The MF world (at
least IBM's MF) has always been extremely reliable and that comes at
a cost. Part of the cost is that there are certain rules that must be
followed and if they aren't followed INCORRECT-OUT (as they say). The
PC side has claimed that small things should not bother programmers.
Well up to a point. LRECL and Blocksize are (in my world) two
different animals. As others have put it blocksize is agreed that it
should be (majority of the time) irrelevant. LRECL is not irrelevant
it is the basic fundamental way units of data are presented to the
programmer and they act on (program for) the information that is
presented in a coherent discreet piece of information. If there is no
rhyme or reason how data is presented how can a programmer program
for data that is essentially unknown? That is almost like speech
recognition or handwriting analasys. You have to have artificial
intelligence and the current computers can't even come close to doing
a reasonable job. And I also think there will have to be a major leap
forward before computers can really do AI.

Remember that one time storage was NOT cheap. Now it is. Also
remember processor cycles were not cheap now they are inexpensive.

Ed
>
> Adam
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@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 ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gerhard Adam]

> I think I would like to suggest that maybe the list as you put it has
> pretty much been there since day 1 of OS/360 (before Virtual Storage). As
> an example we had a IBM SE (yes a real SE) worked up a document (that was
> later published as an orange book) showing optimal blocksizes on tape AND
> buffering the tape and how it would benefit the company ie reduced run
> time faster sorts ect. I believe that his document started development
> on IBM's SAMe (the cost option to make it as a default to do changed
> scheduling and the default buffno to 5. We were amoung the first to buy
> and install the product (we had the black and blue marks to prove it).
> Yes it was rough (although some had worse experiences than we) but we
> stuck at it and got a real benefit from it. It wasn't IBM's most shinning
> moment but we got real value from it and to this day the people that have
> benefited from this product (now included in DFSMS) is real. For an
> example we went from 10 hour processing our nightly batch window to half
> that amount. Yes we needed more storage but the cut in run time saved us
> from buying a larger machine at the time (btw this was at a different
> company). So this did help out at many other companies. No JCL DD
> changes, it installed and it worked.
>

Don't get me wrong. I completely agree that there was tremendous benefit in
making I/O more efficient, however in many cases there were significant
trade-offs that had to be made. I still remember many situations were we
had an 80-100K partition (or region) available to run in, and you can bet
that I wasn't going to waste that space by allocating 5 - 7K buffers (2314
devices) to improve a sequential file's performance. There would have been
virtually no room for the program code if the only concern was optimal
blocking. For selected jobs or high priority work that needed efficiency,
they were generally given the largest amount of memory and CPU access,
precisely for the reasons you stated. However, I also remember many times
having to specify BUFNO=1, just to make a program fit into the storage
available.

Additionally, my point about virtual storage was based on the experience of
having to examine which modules were loaded into memory by the OS to see
which could be removed to avoid virtual storage constraint. Things improved
somewhat with the introduction of MVS, but even so, given the amount of
real-storage available I think many people have forgotten that you couldn't
have 100 CICS regions at 8 MB each running. In today's environment, people
have buffer pools defined that represent far more storage than was available
for several systems in those days, so I/O optimization was something one had
to be judicious about.

>
>
> I am neutral on this issue as the issues you site are somewhat true but
> they are somewhat false. SHould it be transparent... I am really mixed. I
> have seen (somewhat) the PC side and it leads to sloppy programming and
> frequently unpredictable results. Not taking sides too much I would
> rather have predictable results.

I understand what you're saying, but I guess to extend the thought a bit,
my point is really that the more transparent someone is, then the more we
depend on someone else (developers?) to make the decisions for us. In my
mind this will usually result in significantly less flexibility, and will
tend to give external parties the final say in what is considered "optimal".
One of the significant benefits of the mainframe (z/OS) environment, is that
an installation has numerous choices to exploit their particular situation
and means of running a business, while many of the other platforms are quite
rigid in the options available to adapt to differing circumstances. I'm
sure you've seen well-run, as well as poorly run data centers, but at least
the choices and options were available. All too often the alternatives (I'm
thinking PCs here) are like the absurdity of experiencing an error or
software failure and having that stupid pop-up box appear which allows for
the singular option of specifying "OK".

>
> Part of the cost is that there are certain rules that must be followed
> and if they aren't followed INCORRECT-OUT (as they say). The PC side has
> claimed that small things should not bother programmers. Well up to a
> point. LRECL and Blocksize are (in my world) two different animals. As
> others have put it blocksize is agreed that it should be (majority of the
> time) irrelevant. LRECL is not irrelevant it is the basic fundamental way
> units of data are presented to the programmer

I agree. My only point is that in many ways I think its presumptious of
programmers to expect that they shouldn't have to know their chosen craft.

Adam

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[h***@cusys.edu]

On 30 Oct 2007 19:22:47 -0700, ***@CHARTER.NET (Gerhard Adam)
wrote:

>As for "rough transitions", I have to wonder whether people that can't get
>BLKSIZE and LRECL straight in their minds are in any position to be
>designing or developing anything. This is some of the most trivial of the
>trivial problems associated with data management.

Sure they are trivial - until we move into an environment where there
are multiple DASD sizes with different optimal BLKSIZE needs. The
programmer shouldn't care what disk his files are in - the systems
people should have the ability to quickly and easily move the files
depending on current needs. When they move them, they should be able
to adjust the buffering without recompiling and changing JCL.

[Gerhard Adam]

> Sure they are trivial - until we move into an environment where there
> are multiple DASD sizes with different optimal BLKSIZE needs. The
> programmer shouldn't care what disk his files are in - the systems
> people should have the ability to quickly and easily move the files
> depending on current needs. When they move them, they should be able
> to adjust the buffering without recompiling and changing JCL.
>

I don't understand what you're talking about. In today's world there is no
need for an application's programmer to know anything about BLKSIZE beyond
what the installation demands. Utilities can certainly move data between
different geometries and handle the reblocking without intervention. The
JCL and program don't need to specify a blocksize since the DSCB provides
such information. Where exactly is all the effort?

Whether the programmer should care or not is irrelevant. In most cases,
they actually don't know which means that your point has already been made.
The programmer DOESN'T need to know.

Just a question though.. How many different DASD geometries are being
encountered today under z/OS? I am curious about the environment you're
suggesting.

Adam

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Clark F Morris]

On 31 Oct 2007 17:58:09 -0700, in bit.listserv.ibm-main you wrote:

>> Sure they are trivial - until we move into an environment where there
>> are multiple DASD sizes with different optimal BLKSIZE needs. The
>> programmer shouldn't care what disk his files are in - the systems
>> people should have the ability to quickly and easily move the files
>> depending on current needs. When they move them, they should be able
>> to adjust the buffering without recompiling and changing JCL.
>>
>
>I don't understand what you're talking about. In today's world there is no
>need for an application's programmer to know anything about BLKSIZE beyond
>what the installation demands. Utilities can certainly move data between
>different geometries and handle the reblocking without intervention. The
>JCL and program don't need to specify a blocksize since the DSCB provides
>such information. Where exactly is all the effort?
>
>Whether the programmer should care or not is irrelevant. In most cases,
>they actually don't know which means that your point has already been made.
>The programmer DOESN'T need to know.
>
>Just a question though.. How many different DASD geometries are being
>encountered today under z/OS? I am curious about the environment you're
>suggesting.

3380 and 3390 are still valid for disk. Tape blocksizes can be
larger. I still believe that IBM needs to move to FBA. It will take
5 - 10 years but it is ridiculous that the optimal blocksizes for both
3380 and 3390 VSAM make inefficient use of the track if you want the
CI to be in page multiples. It is even dumber since the actual
spinning DASD is FBA.
>
>Adam
>
Clark Morris

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gerhard Adam]

>
> 3380 and 3390 are still valid for disk. Tape blocksizes can be
> larger. I still believe that IBM needs to move to FBA. It will take
> 5 - 10 years but it is ridiculous that the optimal blocksizes for both
> 3380 and 3390 VSAM make inefficient use of the track if you want the
> CI to be in page multiples. It is even dumber since the actual
> spinning DASD is FBA.

This begs the question. Tape, etc are irelevant when it comes to managing
DASD blocksizes which is what all the fuss was about. What I'm curious
about, is for all the points being raised, how many people actually have
3380 and/or 3390's on the floor. Even the point raised here about
inefficient track usage suggests that the originator of the question has a
sense of the physical space usage which I suspect isn't true.

Adam

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Thompson, Steve]

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Tuesday, October 30, 2007 3:09 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: z/OS 1.9 Features summary

On Tue, 30 Oct 2007 18:05:02 +0000, Ted MacNEIL wrote:

<SNIP>
But SDB came too late: if it had been present in rudimentary form,
supplying a valid but nonoptimal BLKSIZE, in OS/360 release 1, coding
BLKSIZE could always have been optional, and much of the rough
transition to present techniques could have been avoided.
<SNIP>

Linkedit had a limit built into it that was never removed. It is what
imposed the 3200 byte blocksize for input text.

Meanwhile, some time before SDB was the ability to establish a blocksize
and use that to get x storage (in the specified blocksize). This was, as
I recall, something done to allow one to move between the 2314 and the
3350 disk drives without having to recalculate the space needed.

Much of what has been carped about here was handled via various ISV
products and finally IBM's DFP group got SMS out so that much of what
you are complaining about could be handled by the system.

But for all these complaints, I would much rather have the IBM system
design than the designs of the BUNCH. And if you aren't old enough to
know who they were, you won't understand.

Regards,
Steve Thompson

-- opinions expressed are strictly my own --

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Edward Jaffe]

Thompson, Steve wrote:
> Linkedit had a limit built into it that was never removed. It is what
> imposed the 3200 byte blocksize for input text.
>

Never removed?

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
***@phoenixsoftware.com
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Howard Brazee]

>
><SNIP>
>But SDB came too late: if it had been present in rudimentary form,
>supplying a valid but nonoptimal BLKSIZE, in OS/360 release 1, coding
>BLKSIZE could always have been optional, and much of the rough
>transition to present techniques could have been avoided.
><SNIP>

It's amazing how hard it is to get shops to implement obvious
improvements. While CoBOL has BLKSIZE=0, lots of people don't use
AVGREC nor IF-THEN-ELSE-ENDIF even today.

We used to calculate out necessary SORTWORK for count-key devices. Now
we just throw more DASD at the job and don't waste our time trying to
be close. But we haven't used the tools provided enough to make the
old ways rare.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Howard Brazee
> Sent: Tuesday, October 30, 2007 3:41 PM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: z/OS 1.9 Features summary
>
>
> >
> ><SNIP>
> >But SDB came too late: if it had been present in rudimentary form,
> >supplying a valid but nonoptimal BLKSIZE, in OS/360 release 1, coding
> >BLKSIZE could always have been optional, and much of the rough
> >transition to present techniques could have been avoided.
> ><SNIP>
>
> It's amazing how hard it is to get shops to implement obvious
> improvements. While CoBOL has BLKSIZE=0, lots of people don't use
> AVGREC nor IF-THEN-ELSE-ENDIF even today.

I agree. I have overheard programmers complaining that they could figure
out the number of cylinders needed for a give number of records. But
they won't look at using the newer (but now quite old) allocation by
number of records. That's because "I understand cylinders".

>
> We used to calculate out necessary SORTWORK for count-key devices. Now
> we just throw more DASD at the job and don't waste our time trying to
> be close. But we haven't used the tools provided enough to make the
> old ways rare.
>

We implemented the ICEMAC to simply override the JCL sortwork and
calculate the amount needed. The only time this fails is when we sort a
file with is compressed using BMC's Data Accelerator product. Then the
poor programmer just try to allocate 12 3390-3 volumes of sortwork and
pray.



--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Clark Morris]

On 30 Oct 2007 13:53:30 -0700, in bit.listserv.ibm-main you wrote:

>> -----Original Message-----
>> From: IBM Mainframe Discussion List
>> [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Howard Brazee
>> Sent: Tuesday, October 30, 2007 3:41 PM
>> To: IBM-***@BAMA.UA.EDU
>> Subject: Re: z/OS 1.9 Features summary
>>
>>
>> >
>> ><SNIP>
>> >But SDB came too late: if it had been present in rudimentary form,
>> >supplying a valid but nonoptimal BLKSIZE, in OS/360 release 1, coding
>> >BLKSIZE could always have been optional, and much of the rough
>> >transition to present techniques could have been avoided.
>> ><SNIP>
>>
>> It's amazing how hard it is to get shops to implement obvious
>> improvements. While CoBOL has BLKSIZE=0, lots of people don't use
>> AVGREC nor IF-THEN-ELSE-ENDIF even today.
>
>I agree. I have overheard programmers complaining that they could figure
>out the number of cylinders needed for a give number of records. But
>they won't look at using the newer (but now quite old) allocation by
>number of records. That's because "I understand cylinders".

Unfortunately for VSAM, allocation in records can give you bad CA
sizes because IBM in their infinite lack of wisdom (excessive sarcasm
but it is one of my hot buttons) decided that we didn't need the
equivalent of ROUND. Thus with the wrong allocation, a data set that
would have a 5 cylinder primary might get an 8 track secondary so the
CI size would be 8 tracks. Need I mention what that does to space
allocation and index levels.
>
>>
>> We used to calculate out necessary SORTWORK for count-key devices. Now
>> we just throw more DASD at the job and don't waste our time trying to
>> be close. But we haven't used the tools provided enough to make the
>> old ways rare.
>>
>
>We implemented the ICEMAC to simply override the JCL sortwork and
>calculate the amount needed. The only time this fails is when we sort a
>file with is compressed using BMC's Data Accelerator product. Then the
>poor programmer just try to allocate 12 3390-3 volumes of sortwork and
>pray.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Thompson, Steve]

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of Edward Jaffe
Sent: Tuesday, October 30, 2007 3:22 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: z/OS 1.9 Features summary

Thompson, Steve wrote:
> Linkedit had a limit built into it that was never removed. It is what
> imposed the 3200 byte blocksize for input text.
>

Never removed?
<SNIP>

Never. Binder replaced it. And just as Binder was coming available I had
the source in my hot little hands (I was a contractor doing development
for IBM at STL at the time) and it was a simple fix. But the person in
charge of the Binder project had control of Linkedit and told me to
leave it alone. Since it was not directly part of the project I was on,
and we could wait for Binder, I dropped it.

Regards,
Steve Thompson

-- Opinions expressed are strictly my own. --

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>>Can you do something other than complain?
>Didn't I say it was improving?

I appologise.
I took the comment as sarcasm.
(The deficiency of text-only communication is determining tone/intent)

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Paul Gilmartin]

On Tue, 30 Oct 2007 13:29:54 -0500, Dave Kopischke wrote:

>On Tue, 30 Oct 2007 09:46:36 -0600, Howard Brazee wrote:
>
>>But why should a program care about block size?
>
>Funny you should ask this; We had a major project implement a couple weeks
>ago. To deal with the number of object moves, many of the libraries were just
>cloned and renamed at implementation time. During this, a couple pretty
>important PDS's were reblocked. A pretty benign change from my point of view.
>
>It turns out a program update process allocates one of these PDS's
>SHR,BLKSIZE=3200. This effectively reblocked the PDS. Every member in this
>PDS that was longer than about 40 lines was corrupted and innaccessible.
>
>That's a reason to care, but probably not the point trying to be made. There
>are code bombs waiting to explode. Even a seemingly benign change can
>trigger one.
>
Ah, but if the programmer hadn't coded BLKSIZE in the DCB but
left it zero and accepted whatever value was in the data set
label, the problem would never have occurred. The problem was
caused by the programmer's delusion that he needed to override
BLKSIZE. And if the OS, according to my idea, had not updated
the BLKSIZE, the data set would not have been corrupted.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Clark F Morris]

On 30 Oct 2007 13:46:07 -0700, in bit.listserv.ibm-main you wrote:

>On Tue, 30 Oct 2007 13:29:54 -0500, Dave Kopischke wrote:
>
>>On Tue, 30 Oct 2007 09:46:36 -0600, Howard Brazee wrote:
>>
>>>But why should a program care about block size?
>>
>>Funny you should ask this; We had a major project implement a couple weeks
>>ago. To deal with the number of object moves, many of the libraries were just
>>cloned and renamed at implementation time. During this, a couple pretty
>>important PDS's were reblocked. A pretty benign change from my point of view.
>>
>>It turns out a program update process allocates one of these PDS's
>>SHR,BLKSIZE=3200. This effectively reblocked the PDS. Every member in this
>>PDS that was longer than about 40 lines was corrupted and innaccessible.
>>
>>That's a reason to care, but probably not the point trying to be made. There
>>are code bombs waiting to explode. Even a seemingly benign change can
>>trigger one.
>>
>Ah, but if the programmer hadn't coded BLKSIZE in the DCB but
>left it zero and accepted whatever value was in the data set
>label, the problem would never have occurred. The problem was
>caused by the programmer's delusion that he needed to override
>BLKSIZE. And if the OS, according to my idea, had not updated
>the BLKSIZE, the data set would not have been corrupted.

All you have to do to foul the works is forget to code BLOCK 0 or use
SYNCSORT with certain input VSAM data sets which it assumes are RECFM
= F or V depending and things go downhill from there.
>
>-- gil
>
Clark Morris

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Tom Schmidt]

On Tue, 30 Oct 2007 18:56:31 -0700, Gerhard Adam wrote:
...lots of setup by John and other good stuff by Adam snipped...
>
> ... But, in truth, I have never heard more
>whining from people that have access to the best tools and technology
>available, yet they can't seem to figure out how to code an IEBGENER job
>stream. Even worse, there has never been more documentation available
than
>there is today, yet the average "programmer" doesn't seem to realize that
>(just like books), PDFs don't read themselves. In the past many people were
>accused of only copying the examples from manuals rather than reading them,
>yet in many ways I wish the current crop would be even that industrious.


I was incensed by this post - because I agreed so intensely with his
sentiment. Now it is going to take me a few seconds longer to get some sleep
tonight.


>I also recognize that there are exceptions to this rant out there and to
>them I apologize for my statements and wish them much luck.

Yeah, me too.

--
Tom Schmidt
Madison, WI
(Don't let my e-mail address fool you - I kept it for convenience; I'm a
practicing sysprog at a z9 customer site)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Tom Marchant]

On Tue, 30 Oct 2007 15:39:23 -0500, Paul Gilmartin wrote:
>
>Ah, but if the programmer hadn't coded BLKSIZE in the DCB but
>left it zero ...

Actually, in COBOL, you had to specify BLOCK CONTAINS ZERO.
Otherwise you got unblocked.

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Howard Brazee]

On 31 Oct 2007 06:22:46 -0700, in bit.listserv.ibm-main you wrote:

>Actually, in COBOL, you had to specify BLOCK CONTAINS ZERO.
>Otherwise you got unblocked.

I've never tried unblocked. I really don't know what happens in that
case.

BLOCK CONTAINS ZERO is what I use, even though it semantically makes
no sense.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Steve Comstock]

Howard Brazee wrote:
> On 31 Oct 2007 06:22:46 -0700, in bit.listserv.ibm-main you wrote:
>
>
>>Actually, in COBOL, you had to specify BLOCK CONTAINS ZERO.
>>Otherwise you got unblocked.
>
>
> I've never tried unblocked. I really don't know what happens in that
> case.
>
> BLOCK CONTAINS ZERO is what I use, even though it semantically makes
> no sense.

If you omit the BLOCK CONTAINS clause, the default is
BLOCK CONTAINS 1 RECORDS. (talk about not making semantic
sense).

A few years ago, changes were made so that for an existing
file OPEN will have the blocksize in the data set label
override the block contains value in the program, even if
the block contains is not zero. (For COBOL only, near as
I can tell.)


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>The word Engineer is in my title as well.

Unless you are a true P. Eng., you are not legally allowed to call yourself (or have your company call you) an engineer.

At least in Canada; I thought the US, as well.

That's why IBM changed the title "Customer Engineer" to "Customer Engineering Representative".

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Ted MacNEIL
> Sent: Wednesday, October 31, 2007 9:50 AM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: z/OS 1.9 Features summary
>
>
> >The word Engineer is in my title as well.
>
> Unless you are a true P. Eng., you are not legally allowed to
> call yourself (or have your company call you) an engineer.
>
> At least in Canada; I thought the US, as well.
>
> That's why IBM changed the title "Customer Engineer" to
> "Customer Engineering Representative".
>

Yeah, well tell that to the HR 'droids. That's why I don't use the
title. Or maybe they have changed it here. I just can't keep up with all
the title changes.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gerhard Postpischil]

Ted MacNEIL wrote:
>> The word Engineer is in my title as well.
>
> Unless you are a true P. Eng., you are not legally allowed to call yourself (or have your company call you) an engineer.
>
> At least in Canada; I thought the US, as well.

In the U.S., there is no federal regulation to that effect, but
rather it varies from state to state. The only one I know that
definitely restricts the use is New Jersey (there was an article
to that effect in ComputerWorld a couple of decades back).


Gerhard Postpischil
Bradford, VT

new e-mail address: gerhardp (at) charter (dot) net

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Rick Fochtman]

--------------------<snip>--------------------

>>> The word Engineer is in my title as well.
>>
>>
>> Unless you are a true P. Eng., you are not legally allowed to call
>> yourself (or have your company call you) an engineer.
>>
>> At least in Canada; I thought the US, as well.
>
---------------------------<unsnip>-------------------------
I guess I just got lucky (???); my title was "Senior Systems Programming
Specialist". :-)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Greg Shirey]

FWIW, from Wikipedia:

"Engineer" as a title

In some countries of Continental Europe and Latin America the title is
limited by law to people with an engineering degree, and the use of the
title by others (even persons with much work experience) is illegal. In
Italy the title is limited to people who, besides holding an engineering
degree, have passed a professional abilitation exam (Esame di Stato).

Laws exist in all U.S. states, Canada and in South Africa which limit
the use of several engineer titles, particularly the title of
"Professional Engineer," and often also titles indicating a specific,
regulated branch of engineering, such as "civil engineer" or "mechanical
engineer." Most U.S. states do not restrict unlicensed persons from
calling themselves an "engineer" or indicating branches or specialties
not covered by the licensing acts, though the legal situation regarding
the title of "engineer" in Canada is unsettled.

Greg

-----Original Message-----
From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
Sent: Wednesday, October 31, 2007 9:50 AM

Unless you are a true P. Eng., you are not legally allowed to call
yourself (or have your company call you) an engineer.

At least in Canada; I thought the US, as well.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Howard Brazee]

On 31 Oct 2007 09:20:20 -0700, in bit.listserv.ibm-main you wrote:

>"Engineer" as a title
>
>In some countries of Continental Europe and Latin America the title is
>limited by law to people with an engineering degree, and the use of the
>title by others (even persons with much work experience) is illegal. In
>Italy the title is limited to people who, besides holding an engineering
>degree, have passed a professional abilitation exam (Esame di Stato).
>
>Laws exist in all U.S. states, Canada and in South Africa which limit
>the use of several engineer titles, particularly the title of
>"Professional Engineer," and often also titles indicating a specific,
>regulated branch of engineering, such as "civil engineer" or "mechanical
>engineer." Most U.S. states do not restrict unlicensed persons from
>calling themselves an "engineer" or indicating branches or specialties
>not covered by the licensing acts, though the legal situation regarding
>the title of "engineer" in Canada is unsettled.

What about historical uses - such as the guy who drives the Train?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Thompson, Steve]

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of Gerhard Postpischil
Sent: Wednesday, October 31, 2007 10:33 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: z/OS 1.9 Features summary

Ted MacNEIL wrote:
>> The word Engineer is in my title as well.
>
> Unless you are a true P. Eng., you are not legally allowed to call
yourself (or have your company call you) an engineer.
>
> At least in Canada; I thought the US, as well.

In the U.S., there is no federal regulation to that effect, but rather
it varies from state to state. The only one I know that definitely
restricts the use is New Jersey (there was an article to that effect in
ComputerWorld a couple of decades back).
<SNIP>

Let's see, there is Texas, Ohio, Pennsylvania, Maryland...

And Texas and New Jersey were at one time playing with making Software
Engineer a reality. However, New Jersey thought that the board to
control the new Software Engineer group should report to Cosmetology.
This caused an uproar, and that got completely derailed as a
hair-brained idea (and no, I'm not joking).

Regards,
Steve Thompson

-- Opinions expressed are strictly my own. --

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>BLOCK CONTAINS ZERO is what I use, even though it semantically makes no sense

It's actually short for:
BLOCK CONTAINS ZERO RECORDS

The key word RECORDS is now optional.
It wasn't 30 years ago, when I learned COBOL.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Kelman, Tom]

> On 31 Oct 2007 09:20:20 -0700, in bit.listserv.ibm-main Howard Brazee
wrote:
>
> >"Engineer" as a title
> >
> >In some countries of Continental Europe and Latin America the title
is
> >limited by law to people with an engineering degree, and the use of
the
> >title by others (even persons with much work experience) is illegal.
In
> >Italy the title is limited to people who, besides holding an
engineering
> >degree, have passed a professional abilitation exam (Esame di Stato).
> >
> >Laws exist in all U.S. states, Canada and in South Africa which limit
> >the use of several engineer titles, particularly the title of
> >"Professional Engineer," and often also titles indicating a specific,
> >regulated branch of engineering, such as "civil engineer" or
"mechanical
> >engineer." Most U.S. states do not restrict unlicensed persons from
> >calling themselves an "engineer" or indicating branches or
specialties
> >not covered by the licensing acts, though the legal situation
regarding
> >the title of "engineer" in Canada is unsettled.
>
> What about historical uses - such as the guy who drives the Train?
>
> ----------------------------------------------------------------------
That is also mentioned in the same Wikipedia article.

"In the United States, the term "engineer" is also used to denote an
operator of an engine of some sort, e.g., a railroad engineer denotes
the operator of a locomotive, a ship's engineer denotes the operator of
the steam engine on a steamship, and a stationary engineer is normally
responsible for a stationary steam engine. Occasionally "title
inflation" results in non-engineers holding jobs with "engineer" in the
job title. For example, the term "field engineer" is often used to
describe manufacturers' (or third party) supplied installers and/or
maintainers of (complex) equipment at a user's site. However, they are
not commonly degreed engineers."

Also in the same article there is this. You can't call yourself a
Microsoft Certified Systems Engineer in Canada. I would guess that
applies to the term Software Engineer also. As the holder of an actual
electrical engineering degree (although no longer used) I applaud that.
I am now a capacity planner, not a capacity planning engineer. It takes
more than a few months study to get a true engineering degree.

"In Canada, the usage of the term "engineer" to describe holders of
professional certification is not legally permitted. The Canadian
Council of Professional Engineers mounted an extended campaign to get
Microsoft to renounce use of the word "engineer" in the title of their
certification.[5] A 2001 reader survey by Microsoft Certified
Professional magazine found that over half of respondents supported
changing the name of the MCSE to remove the word "engineer".[6]"


Tom Kelman



*****************************************************************************
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*****************************************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Paul Gilmartin]

On Wed, 31 Oct 2007 12:51:11 -0700, Steve Comstock wrote:
>
>If you omit the BLOCK CONTAINS clause, the default is
>BLOCK CONTAINS 1 RECORDS. (talk about not making semantic
>sense).
>
It isn't even syntactically correct.

But the original COBOL designers were pessimists. They never
imagined that IBM would ever DTRT and supply a system default
blocking factor. So, the default was 1, meaningful only
diachronically, not 0 which is practical synchronically.

>A few years ago, changes were made so that for an existing
>file OPEN will have the blocksize in the data set label
>override the block contains value in the program, even if
>the block contains is not zero. (For COBOL only, near as
>I can tell.)
>
Obviously, the change is in the COBOL RTL, not in the
access method. Once again, IBM designers DTRT but in
the wrong layer. This should have been fixed in the
access method so it would benefit all applications, not
in the COBOL RTL where it benefits only COBOL.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Steve Comstock]

Paul Gilmartin wrote:
> On Wed, 31 Oct 2007 12:51:11 -0700, Steve Comstock wrote:
>
>>If you omit the BLOCK CONTAINS clause, the default is
>>BLOCK CONTAINS 1 RECORDS. (talk about not making semantic
>>sense).
>>
>
> It isn't even syntactically correct.

Well, it is syntactically correct as far as the COBOL
language goes. The syntax here only allows the plural
form of RECORDS, regardless of the count.


[snip]


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>This should have been fixed in the access method so it would benefit all applications, not in the COBOL RTL where it benefits only COBOL.

"Fixing" blocking factors has always been a performance issue.

I remember, shortly after becoming a performance analyst (1981), my ex-wife (application [COBOL] programmer) came to me with a problem with a (tape) batch problem that the entire stream was taking forever (and longer) to run.
It had this tape file that was being passed around from job to job.
I recommended things like VOL=(,,,RETAIN), which dropped OPS intervention, but then I had her look at the DCB.
It was LRECL=BLKSIZE=80 (on tape!).
I told her to change the JCL to create what ever BLKSIZE is close to 32756 (I never remember the number -- I use SDB, now).
The COBOL programmes all had BLOCK CONTAINS ZERO.
The first run of the stream ran in less than 30 minutes.
She actually got paged because OPS thought it had failed since it ran so long before.
She got a promotion/raise out of it; I got (well never mind!).

But, this issue has been sticking around (especially with the knowledge disappearing/retiring), and getting worse.

That is why I am such a proponent of SMS.
IF (BIG IF) you implement it correctly, you can take the access method details out of the hands of the (less storage savvy) application programmers.

But, SMS doesn't stand alone.
We need the compilers/assemblers to understand this, as well.


-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>How many different DASD geometries are being
encountered today under z/OS?

As inefficient as it may seem, IBM promised (a long time ago) that they would not change the geometry of disk.
So, it comes down to two BLKSIZES: DASD & Tape.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gerhard Adam]

> >How many different DASD geometries are being
> encountered today under z/OS?
>
> As inefficient as it may seem, IBM promised (a long time ago) that they
> would not change the geometry of disk.
> So, it comes down to two BLKSIZES: DASD & Tape.

Exactly ... which is why I don't understand all the talk about different
DASD sizes and blocking factors.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Kopischke]

Another take on z/os 1.9 from SearchDataCenter yesterday....

A REVIEW OF Z/OS 1.9 FEATURES
Robert Crawford, Contributor

IBM's mainframe operating system, z/OS 1.9, is now generally available. This
release has its share of enhancements both large and small. What follows are
those that caught the eye of expert Robert Crawford.


http://searchdatacenter.techtarget.com/tip/0,289483,sid80_gci1280330,00.ht
ml?track=NL-576&ad=611332&asrc=EM_NLT_2483474&uid=279318

Mind the wrap.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Steve Comstock]

Dave Kopischke wrote:
> Another take on z/os 1.9 from SearchDataCenter yesterday....
>
> A REVIEW OF Z/OS 1.9 FEATURES
> Robert Crawford, Contributor
>
> IBM's mainframe operating system, z/OS 1.9, is now generally available. This
> release has its share of enhancements both large and small. What follows are
> those that caught the eye of expert Robert Crawford.
>
>
> http://searchdatacenter.techtarget.com/tip/0,289483,sid80_gci1280330,00.ht
> ml?track=NL-576&ad=611332&asrc=EM_NLT_2483474&uid=279318
>
> Mind the wrap.

Yeah, more of a systems perspective. Thanks.

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Of course IBM should provide a compile option to default to BLOCK = 0 in the FD statement for COBOL.

Raise a requirement.
They are not going to make changes based on comments on IBM-Main (pet peeve).

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Clark Morris]

On 3 Nov 2007 18:09:26 -0700, in bit.listserv.ibm-main Ted wrote:

>>Of course IBM should provide a compile option to default to BLOCK = 0 in the FD statement for COBOL.
>
>Raise a requirement.
>They are not going to make changes based on comments on IBM-Main (pet peeve).

I may have done so. Those of you who are actually working (I'm
retired until someone offers me a contract on the applications side or
systems if they are willing to overlook my not having done systems
programming in over 15 years) are in a better position to submit the
requirement.
>
>-
>Too busy driving to stop for gas!
>
Clark Morris

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Eric Bielefeld]

Clark,

I've got just the opposite thing. I'm looking for a Cobol programming job,
which in Milwaukee are way more plentifull than systems programmer jobs. I
have about 2 years experience from about 25 years ago. I still would
greatly prefer work as a sysprog, but there have been to my estimation maybe
2 or 3 jobs open in the last 3 years in the Milwaukee area.

Eric Bielefeld
Sr. z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434

----- Original Message -----
From: "Clark Morris" <***@NS.SYMPATICO.CA>
> I may have done so. Those of you who are actually working (I'm
> retired until someone offers me a contract on the applications side or
> systems if they are willing to overlook my not having done systems
> programming in over 15 years) are in a better position to submit the
> requirement.
>>
> Clark Morris

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Eric Bielefeld]

I have a question about the IEEE Computer Society. They are offering me a 1
year membership, and they say they offer free training in 1,300 classes,
including Java, Oracle, etc. Has anyone taken their online training
courses? Are the courses any good? I want to learn Java so I will have a
better chance of getting a programmer position, as that seems to be the hot
language now.

Eric Bielefeld
Sr. z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html