Re: Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[John Gilmore]

Google aside, 'ça' has two meanings:

o It is an abbreviation of 'cela', a demonstrative pronoun, as in
'C'est ça!', That's right! .

o It is also an adverb, 'here' or 'hither', as in 'ça et la', here and there.

As Paul Gilmartin all but said, it is always written/printed as 'ça'.
If it were written as ''ca', it would be pronounced 'ka', as in
'cabane' , ka'ban, not  'sa', as in 'façade', fa'sahd.

French is a Latin dialect, and the complete text of Pliny the
Younger's apothegm:

Errare humanum est, perseverare autem diabolicum.

is relevant here.  To err is human; to persist in it is diabolical.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Base-less programming

[Bernd Oppolzer]

Cross-Posted to IBM-Main and IBM-ASSEMBLER-List

I believe it has been discussed before:

the term "baseless programming" is an over-simplification.
It should be "an ASSEMBLER programming technique, where the
code area is not covered by base registers" - which requires
separation of code area and data area and relative branch instructions;
take care of your literals.

If you have large code areas, this may save you some registers,
or you may save some time otherwise needed to save and reload
the registers which cover the code area.

I managed to convert most of our inhouse macros in the last few months
to "baseless", including the site-specific SP macros, so now I don't have
restrictions regarding the size of the code areas any more. Of course,
it is not good to have large code areas (small functional blocks are 
better),

but if you want to add trace output macros or other test facilities to a
functional block, you don't like it if code area size restrictions 
prevent you

from doing it. This was the main reason for my "baseless" effort - I had
to do some maintenance to some very large and very old programs, and
the only way to do it was to add some trace output.

Thanks to Ed Jaffe for the link to the SHARE presentation, BTW.

Kind regards

Bernd




Am 06.12.2013 02:05, schrieb John McKown:

On Thu, Dec 5, 2013 at 6:09 PM, zMan  wrote:


Ouch. SO true.


Yes. In this same vein, but a bit more seriously, why don't we start using
RI-programming (for Relative & Immediate) or RelImm-programming. Because
there is _no_ way that I can think of to write _useful_ code which does not
use at least a few base+displacement instructions. At the very least for
the incoming parameter list. Well, maybe a random() type program could be
written without using any base+displacement instructions if it did some
sort of manipulation of the data returned by the STCKE instruction instead
of having a seed and basing the current result on the previous one.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Restore Multi-Volume GDG from Virtual Tape?

[Nathan J Pfister]

List;

Is it possible to restore a multi-voulme GDG from Virtual Tape.  It was a 
47-volume (Mod-9) dataset, an SMF Dump, and we are trying to restore it. 
We've tried quite a bit of different ADRDSSU code with no luck.

//REST01 EXEC PGM=ADRDSSU,
//   PARM='UTILMSG=YES',
//   REGION=6M,
//   TIME=1400
//SYSPRINT   DD SYSOUT=*
//TAPE01 DD DSN=BACKUP.AKM93B1F,
//   DISP=(OLD,KEEP),UNIT=VTL,
//   LABEL=(12,SL),
//   VOL=SER=439394
//TAPE02 DD DSN=BACKUP.AKM9A61D,
//   DISP=(OLD,KEEP),UNIT=VTL,
//   LABEL=(6,SL),
//   VOL=SER=387231
.
//TAPE47 DD DSN=BACKUP.AKM933AF,
//   DISP=(OLD,KEEP),UNIT=VTL,
//   LABEL=(7,SL),
//   VOL=SER=395208
//SYSIN  DD *
 RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
 INDD(TAPE01) OUTDY(NEFA10) BYPASSACS(**) NULLSTORCLAS ADMIN -
 FORCE 
 RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
 INDD(TAPE02) OUTDY(NEFA11) BYPASSACS(**) NULLSTORCLAS ADMIN -
 FORCE 

 RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
 INDD(TAPE47) OUTDY(NEFA3E) BYPASSACS(**) NULLSTORCLAS ADMIN -
 FORCE 



Above is our latest attempt.  Any help would be appreciated.  Thanks!


Thanks;

Nathan Pfister
zOS Systems Programmer

This message contains privileged and confidential information intended for the 
above addressees only.  If you 
receive this message in error please delete or destroy this message and/or 
attachments.  

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging 
in the unauthorized use of this message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Restore Multi-Volume GDG from Virtual Tape?

[R.S.]

Details depend on details.

How it was dumped?
It looks like several unrelated dump datasets, each containing part of 
your SMF archive. It doesn't make sense.
More, it seems you tape volumes (virtual=> relatively small) are 
muti-file volumes. So you use part of small tape volume, but you use 
plenty of them.



--
Radoslaw Skorupka
Lodz, Poland








W dniu 2013-12-06 15:18, Nathan J Pfister pisze:

List;

Is it possible to restore a multi-voulme GDG from Virtual Tape.  It was a
47-volume (Mod-9) dataset, an SMF Dump, and we are trying to restore it.
We've tried quite a bit of different ADRDSSU code with no luck.

//REST01 EXEC PGM=ADRDSSU,
//   PARM='UTILMSG=YES',
//   REGION=6M,
//   TIME=1400
//SYSPRINT   DD SYSOUT=*
//TAPE01 DD DSN=BACKUP.AKM93B1F,
//   DISP=(OLD,KEEP),UNIT=VTL,
//   LABEL=(12,SL),
//   VOL=SER=439394
//TAPE02 DD DSN=BACKUP.AKM9A61D,
//   DISP=(OLD,KEEP),UNIT=VTL,
//   LABEL=(6,SL),
//   VOL=SER=387231
.
//TAPE47 DD DSN=BACKUP.AKM933AF,
//   DISP=(OLD,KEEP),UNIT=VTL,
//   LABEL=(7,SL),
//   VOL=SER=395208
//SYSIN  DD *
  RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
  INDD(TAPE01) OUTDY(NEFA10) BYPASSACS(**) NULLSTORCLAS ADMIN -
  FORCE
  RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
  INDD(TAPE02) OUTDY(NEFA11) BYPASSACS(**) NULLSTORCLAS ADMIN -
  FORCE

  RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
  INDD(TAPE47) OUTDY(NEFA3E) BYPASSACS(**) NULLSTORCLAS ADMIN -
  FORCE



Above is our latest attempt.  Any help would be appreciated.  Thanks!


Thanks;

Nathan Pfister
zOS Systems Programmer

This message contains privileged and confidential information intended for the 
above addressees only.  If you
receive this message in error please delete or destroy this message and/or 
attachments.

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging
in the unauthorized use of this message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl 
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.555.904 zote.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Base-less programming

[Scott Ford]

Bernd,

Ty for your thread. Some of us unfortunately work in multiple languages are of 
course are getting older, so we may have to ask about a design or concept more 
than once..yes I am older and I have a condition which makes focusing sometimes 
difficult...

That being said, my reason for baseless code is eliminating multiple base 
register usage and maintain ability..am I wrong here ?

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


> On Dec 6, 2013, at 9:20 AM, Bernd Oppolzer  wrote:
> 
> Cross-Posted to IBM-Main and IBM-ASSEMBLER-List
> 
> I believe it has been discussed before:
> 
> the term "baseless programming" is an over-simplification.
> It should be "an ASSEMBLER programming technique, where the
> code area is not covered by base registers" - which requires
> separation of code area and data area and relative branch instructions;
> take care of your literals.
> 
> If you have large code areas, this may save you some registers,
> or you may save some time otherwise needed to save and reload
> the registers which cover the code area.
> 
> I managed to convert most of our inhouse macros in the last few months
> to "baseless", including the site-specific SP macros, so now I don't have
> restrictions regarding the size of the code areas any more. Of course,
> it is not good to have large code areas (small functional blocks are better),
> but if you want to add trace output macros or other test facilities to a
> functional block, you don't like it if code area size restrictions prevent you
> from doing it. This was the main reason for my "baseless" effort - I had
> to do some maintenance to some very large and very old programs, and
> the only way to do it was to add some trace output.
> 
> Thanks to Ed Jaffe for the link to the SHARE presentation, BTW.
> 
> Kind regards
> 
> Bernd
> 
> 
> 
> 
> Am 06.12.2013 02:05, schrieb John McKown:
>> On Thu, Dec 5, 2013 at 6:09 PM, zMan  wrote:
>> 
>>> Ouch. SO true.
>> Yes. In this same vein, but a bit more seriously, why don't we start using
>> RI-programming (for Relative & Immediate) or RelImm-programming. Because
>> there is _no_ way that I can think of to write _useful_ code which does not
>> use at least a few base+displacement instructions. At the very least for
>> the incoming parameter list. Well, maybe a random() type program could be
>> written without using any base+displacement instructions if it did some
>> sort of manipulation of the data returned by the STCKE instruction instead
>> of having a seed and basing the current result on the previous one.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "NSA foils much internet encryption"

[DASDBILL2]

Apple's lawyers are very clever. As lawyers all know, show them a law (e.g., 
Section 215 of the USA Patriot Act) and they will show you a loophole (e.g., 
warrant canary). 
  
Bill Fairchild 
Franklin, TN 
  
N.B. :  I have never received an order under Section 215 of the USA Patriot 
Act.  I would expect to challenge such an order if served on me. 
  

- Original Message -

From: "Paul Gilmartin"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, December 5, 2013 5:41:59 PM 
Subject: Re: "NSA foils much internet encryption" 

On Thu, 5 Dec 2013 15:19:55 -0600, Mike Schwab  wrote: 

>Microsoft finally woke up. 
> 
>http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/05/microsoft-u-s-government-is-a-potential-security-threat/
> 
> 
>Microsoft is trying to change the terms of the NSA debate � literally. 
> 
>The company is labeling any government effort to spy on its online 
>communications as evidence of an "advanced persistent threat," a term 
>that's so far been reserved to describe foreign espionage units such 
>as the one allegedly operated by the Chinese military. 
> 
Related: 

    
http://techcrunch.com/2013/11/05/apple-slips-in-warrant-canary-to-warn-users-of-future-compliance-with-patriot-act-section-215-information-requests/
 

... and my vocabulary is enlarged. 

-- gil 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Restore Multi-Volume GDG from Virtual Tape?

[Mike Schwab]

If these are logical backups, the first volume should contain the entire backup.

If these are physical backups, I would restore  / rename each volume's
dataset as an independent dataset (data.set.name.g1234v00.vol001),
then copy all the datasets (concatenated input) to a VTAPE dataset
then delete the parts and copy the vtape back to disk.

On Fri, Dec 6, 2013 at 8:18 AM, Nathan J Pfister
 wrote:
> List;
>
> Is it possible to restore a multi-voulme GDG from Virtual Tape.  It was a
> 47-volume (Mod-9) dataset, an SMF Dump, and we are trying to restore it.
> We've tried quite a bit of different ADRDSSU code with no luck.
>
> //REST01 EXEC PGM=ADRDSSU,
> //   PARM='UTILMSG=YES',
> //   REGION=6M,
> //   TIME=1400
> //SYSPRINT   DD SYSOUT=*
> //TAPE01 DD DSN=BACKUP.AKM93B1F,
> //   DISP=(OLD,KEEP),UNIT=VTL,
> //   LABEL=(12,SL),
> //   VOL=SER=439394
> //TAPE02 DD DSN=BACKUP.AKM9A61D,
> //   DISP=(OLD,KEEP),UNIT=VTL,
> //   LABEL=(6,SL),
> //   VOL=SER=387231
> .
> //TAPE47 DD DSN=BACKUP.AKM933AF,
> //   DISP=(OLD,KEEP),UNIT=VTL,
> //   LABEL=(7,SL),
> //   VOL=SER=395208
> //SYSIN  DD *
>  RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
>  INDD(TAPE01) OUTDY(NEFA10) BYPASSACS(**) NULLSTORCLAS ADMIN -
>  FORCE
>  RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
>  INDD(TAPE02) OUTDY(NEFA11) BYPASSACS(**) NULLSTORCLAS ADMIN -
>  FORCE
> 
>  RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
>  INDD(TAPE47) OUTDY(NEFA3E) BYPASSACS(**) NULLSTORCLAS ADMIN -
>  FORCE
>
>
>
> Above is our latest attempt.  Any help would be appreciated.  Thanks!
>
>
> Thanks;
>
> Nathan Pfister
> zOS Systems Programmer
>
> This message contains privileged and confidential information intended for 
> the above addressees only.  If you
> receive this message in error please delete or destroy this message and/or 
> attachments.
>
> The sender of this message will fully cooperate in the civil and criminal 
> prosecution of any individual engaging
> in the unauthorized use of this message.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "NSA foils much internet encryption"

[Paul Gilmartin]

On Fri, 6 Dec 2013 14:58:36 +, DASDBILL2 wrote:

>Apple's lawyers are very clever. As lawyers all know, show them a law (e.g., 
>Section 215 of the USA Patriot Act) and they will show you a loophole (e.g., 
>warrant canary). 
>   
Perhaps the DoHS lawyers are also clever.  I wonder whether they'd be able
to construe any affirmative step taken by an Apple executive to smother the
canary in the event of a Section 215 warrant as a violation of the gag order.

>N.B. :  I have never received an order under Section 215 of the USA Patriot 
>Act.  I would expect to challenge such an order if served on me. 
>  
>- Original Message -
>
>From: "Paul Gilmartin"
>Sent: Thursday, December 5, 2013 5:41:59 PM 
>
>On Thu, 5 Dec 2013 15:19:55 -0600, Mike Schwab wrote: 
>
>>Microsoft finally woke up. 
>> 
>>http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/05/microsoft-u-s-government-is-a-potential-security-threat/
>> 
>> 
>Related: 
>
>    
>http://techcrunch.com/2013/11/05/apple-slips-in-warrant-canary-to-warn-users-of-future-compliance-with-patriot-act-section-215-information-requests/
> 

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "NSA foils much internet encryption"

[John Gilmore]

There is a large legal literature of omisses, instances of omissis.
The upshot is that failing to do something that is positively required
is actionable but that negative omissis, failing to renew a guarantee,
offer a refund, make paint in the color burnt umber, etc.,etc., is
not.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Base-less programming

[Bernd Oppolzer]

Just to give some more explanations:

we have at our site some macros, which allow the structuring of large
ASSEMBLER programs in subroutines. There is a mainline, which is
started by a startup macro (let's call it PSTART), which does all the 
linkage

conventions and establishes some base registers for the code and
data area. The number of base registers for the code area is not limited,
but normally should not exceed 3, that makes a code area of 12 k.
The registers may be specified on the PSTART macro call.

Then there are subroutine macros, let's say PPROC and PEND.
PPROC establishes two registers for the code area, which limits
each "PROC" to 8k. Again, the registers may be specified on the
the PPROC macro call.

Of course, the registers may be reused for every new PROC. So already
in the past, programs of virtually umlimited size were possible.

Each PROC can have "local" variables that are located behind the
PEND macro and are accessible only from this PROC.

Now:

By converting the PPROC and PEND macros (and all other macros)
to "baseless", I was able to remove the 8k restriction for the PPROC / PEND
blocks, and I only needed one base register, because I didn't need to
cover the code area any more; I only covered the static data area
behind the PEND macro (and limited it to 4k in the normal case).
The code area may grow without limit, as long as the relativ branches
reach their targets.

I hope this gives you an idea what I did when I converted our environment
to "baseless".

Kind regards

Bernd




Am 06.12.2013 15:45, schrieb Scott Ford:

Bernd,

Ty for your thread. Some of us unfortunately work in multiple languages are of 
course are getting older, so we may have to ask about a design or concept more 
than once..yes I am older and I have a condition which makes focusing sometimes 
difficult...

That being said, my reason for baseless code is eliminating multiple base 
register usage and maintain ability..am I wrong here ?

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'



On Dec 6, 2013, at 9:20 AM, Bernd Oppolzer  wrote:

Cross-Posted to IBM-Main and IBM-ASSEMBLER-List

I believe it has been discussed before:

the term "baseless programming" is an over-simplification.
It should be "an ASSEMBLER programming technique, where the
code area is not covered by base registers" - which requires
separation of code area and data area and relative branch instructions;
take care of your literals.

If you have large code areas, this may save you some registers,
or you may save some time otherwise needed to save and reload
the registers which cover the code area.

I managed to convert most of our inhouse macros in the last few months
to "baseless", including the site-specific SP macros, so now I don't have
restrictions regarding the size of the code areas any more. Of course,
it is not good to have large code areas (small functional blocks are better),
but if you want to add trace output macros or other test facilities to a
functional block, you don't like it if code area size restrictions prevent you
from doing it. This was the main reason for my "baseless" effort - I had
to do some maintenance to some very large and very old programs, and
the only way to do it was to add some trace output.

Thanks to Ed Jaffe for the link to the SHARE presentation, BTW.

Kind regards

Bernd



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Dynamic TELNET profile changes

[Dennis Black]

In the TELNETPARMS section of the profile I need to replace the PORT 23 
statement with TTLSPORT 23 and add CONNTYPE ANY dynamically, using the 
OBERYFILE command. I'm not sure of the syntax of what portion of the section 
needs to be included. Will the entire content of the section need to be 
included, with the changes, or simply the new parameters. And will adding the 
TTLS PORT 23 parm automatically replace the PORT 23 parm or is there a specific 
way of deleting then replacing it? Is anyone familiar?

Dennis Black | Information Technology Professional III
State of Nevada | DoA | Enterprise Information Technology Services
E: dhbl...@admin.nv.gov



This communication, including any attachments, may contain confidential 
information and is intended only for the individual or entity to which it is 
addressed. Any review, dissemination or copying of this communication by anyone 
other than the intended recipient is strictly prohibited. If you are not the 
intended recipient, please contact the sender by reply e-mail and delete all 
copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Exit interfaces and module attributes (was: Base-less ...)

[Paul Gilmartin]

This thread seems to nave diverged into ASSEMBLER-LIST and
IBM-MAIN.  I'm extending the topic.  A contributor said in
ASSEMBLER LIST:

... I am trying to decide to convert it to baseless or write an
assembler stub and redo the exit in C.

In a perfect universe, a stub would be needless.

About 40 years ago, before I had any OS/360 exposure, an Expert
boasted to me that the calling conventions of OS were absolutely
homogeneous -- a subroutine in any language could be called from
any other language, or as a main program alike.  (I was skeptical --
I asked, "LISP?  SNOBOL4?"  My mentor replied, "Of course!")

What have we lost?

With XA, the facility was mostly preserved: CSECTs were marked
AMODE 24 or AMODE 31; would be entered in the correct AMODE,
and would return to a caller in the caller's mode via BSM.

So, daydream/wishlist item:  It should be made possible to mark
a load module as LE-mode so ATTACH or an EXIT interface would
seamlessly enter an exit written in LE C (not just Metal C) and the
exit return smoothly.

Would Metal C remove the need for an Assembler stub?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Restore Multi-Volume GDG from Virtual Tape?

[retired mainframer]

It would really help if you could post the listing of the job that dumped
the dataset.  Barring that, we need to see the JCL for the dump job.

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of Nathan J Pfister
:>: Sent: Friday, December 06, 2013 6:19 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Restore Multi-Volume GDG from Virtual Tape?
:>:
:>: List;
:>:
:>: Is it possible to restore a multi-voulme GDG from Virtual Tape.  It was
:>: a
:>: 47-volume (Mod-9) dataset, an SMF Dump, and we are trying to restore it.
:>: We've tried quite a bit of different ADRDSSU code with no luck.
:>:
:>: //REST01 EXEC PGM=ADRDSSU,
:>: //   PARM='UTILMSG=YES',
:>: //   REGION=6M,
:>: //   TIME=1400
:>: //SYSPRINT   DD SYSOUT=*
:>: //TAPE01 DD DSN=BACKUP.AKM93B1F,
:>: //   DISP=(OLD,KEEP),UNIT=VTL,
:>: //   LABEL=(12,SL),
:>: //   VOL=SER=439394
:>: //TAPE02 DD DSN=BACKUP.AKM9A61D,
:>: //   DISP=(OLD,KEEP),UNIT=VTL,
:>: //   LABEL=(6,SL),
:>: //   VOL=SER=387231
:>: .
:>: //TAPE47 DD DSN=BACKUP.AKM933AF,
:>: //   DISP=(OLD,KEEP),UNIT=VTL,
:>: //   LABEL=(7,SL),
:>: //   VOL=SER=395208
:>: //SYSIN  DD *
:>:  RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
:>:  INDD(TAPE01) OUTDY(NEFA10) BYPASSACS(**) NULLSTORCLAS ADMIN -
:>:  FORCE
:>:  RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
:>:  INDD(TAPE02) OUTDY(NEFA11) BYPASSACS(**) NULLSTORCLAS ADMIN -
:>:  FORCE
:>: 
:>:  RESTORE DS(INCLUDE(TAPE.SMF.DUMP.NX.G5203V00)) -
:>:  INDD(TAPE47) OUTDY(NEFA3E) BYPASSACS(**) NULLSTORCLAS ADMIN -
:>:  FORCE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Exit interfaces and module attributes (was: Base-less ...)

[Scott Ford]

Gil,

I appreciate what you said. In the perfect world ( wasn't that a Blondie song), 
the API calls, linkage between languages would be well documented and extensive 
samples.  But life and code and development sometimes are messy, so 
experimentation is necessary. I ask questions, because like many of my 
colleagues I don't have all the answers, especially when I looking at a new 
design or concept. Times have changed no more PLMs or source to look at ...so 
here we are...

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


> On Dec 6, 2013, at 1:22 PM, Paul Gilmartin  wrote:
> 
> This thread seems to nave diverged into ASSEMBLER-LIST and
> IBM-MAIN.  I'm extending the topic.  A contributor said in
> ASSEMBLER LIST:
> 
>... I am trying to decide to convert it to baseless or write an
>assembler stub and redo the exit in C.
> 
> In a perfect universe, a stub would be needless.
> 
> About 40 years ago, before I had any OS/360 exposure, an Expert
> boasted to me that the calling conventions of OS were absolutely
> homogeneous -- a subroutine in any language could be called from
> any other language, or as a main program alike.  (I was skeptical --
> I asked, "LISP?  SNOBOL4?"  My mentor replied, "Of course!")
> 
> What have we lost?
> 
> With XA, the facility was mostly preserved: CSECTs were marked
> AMODE 24 or AMODE 31; would be entered in the correct AMODE,
> and would return to a caller in the caller's mode via BSM.
> 
> So, daydream/wishlist item:  It should be made possible to mark
> a load module as LE-mode so ATTACH or an EXIT interface would
> seamlessly enter an exit written in LE C (not just Metal C) and the
> exit return smoothly.
> 
> Would Metal C remove the need for an Assembler stub?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Wayne Bickerdike]

*d'accord*


On Sat, Dec 7, 2013 at 12:55 AM, John Gilmore  wrote:

> Google aside, 'ça' has two meanings:
>
> o It is an abbreviation of 'cela', a demonstrative pronoun, as in
> 'C'est ça!', That's right! .
>
> o It is also an adverb, 'here' or 'hither', as in 'ça et la', here and
> there.
>
> As Paul Gilmartin all but said, it is always written/printed as 'ça'.
> If it were written as ''ca', it would be pronounced 'ka', as in
> 'cabane' , ka'ban, not  'sa', as in 'façade', fa'sahd.
>
> French is a Latin dialect, and the complete text of Pliny the
> Younger's apothegm:
>
> Errare humanum est, perseverare autem diabolicum.
>
> is relevant here.  To err is human; to persist in it is diabolical.
>
> John Gilmore, Ashland, MA 01721 - USA
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Exit interfaces and module attributes (was: Base-less ...)

[John McKown]

On Fri, Dec 6, 2013 at 12:22 PM, Paul Gilmartin wrote:

> This thread seems to nave diverged into ASSEMBLER-LIST and
> IBM-MAIN.  I'm extending the topic.  A contributor said in
> ASSEMBLER LIST:
>
> ... I am trying to decide to convert it to baseless or write an
> assembler stub and redo the exit in C.
>
> In a perfect universe, a stub would be needless.
>
> About 40 years ago, before I had any OS/360 exposure, an Expert
> boasted to me that the calling conventions of OS were absolutely
> homogeneous -- a subroutine in any language could be called from
> any other language, or as a main program alike.  (I was skeptical --
> I asked, "LISP?  SNOBOL4?"  My mentor replied, "Of course!")
>
> What have we lost?
>
> With XA, the facility was mostly preserved: CSECTs were marked
> AMODE 24 or AMODE 31; would be entered in the correct AMODE,
> and would return to a caller in the caller's mode via BSM.
>
> So, daydream/wishlist item:  It should be made possible to mark
> a load module as LE-mode so ATTACH or an EXIT interface would
> seamlessly enter an exit written in LE C (not just Metal C) and the
> exit return smoothly.
>

ATTACH shouldn't need to know whether a module is LE or not. The way that a
main program is bound results in the LE environment being initialized
before the first user code. The problem with EXITs, especially OS type
exits, is that LE  might not be initialized. And initializing it is
"expensive" because it sets up a lot of environmental stuff, such as a HEAP
and a STACK.


>
> Would Metal C remove the need for an Assembler stub?
>

AFAIK, yes it removes the need for assembler because Metal C could also be
called "non-LE C". I.e. the routines it generates do not depend on LE being
initialized. Which is why it has restrictions on what it can do, compared
to the "full C" compile.

One other environment you did not mention was XP linkage, used by the C run
time. It greatly changes the OS calling convention because it passes
parameters in general and floating registers instead of via the parm list
pointed to by GPR1.


>
> -- gil
>
>

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Something to Think About - Optimal PDS Blocking

[Dyck, Lionel]

We all know about system determined blksize and there have been rules of thumb 
for decades about the correct/optimal blksize to use for each type of PDS.

My question is what is the optimal blksize for a PDS based on the member sizes?

Having a large a blksize with many small members results in many blocks with 
wasted space. Having a small blksize with many large members results in 
unnecessary I/O to read all the blocks of data.

The various tools available to provide a best estimate at optimal blksize (e.g. 
trkcalc, blkdisk, blk3390) and even SDB all provide a best estimate without 
having any awareness of the planned, or existing, contents of the PDS.

Which is better - a BLKSIZE of 3120 with 100 members ranging from 3 to 30 
records or that same set of records in a PDS with BLKSIZE of 27920. And 
similarly what about a PDS with BLKSIZE of 3120 and 100 members ranging from 
300 to 9000 records compared to the same set of records in a PDS with a BLKSIZE 
of 27920.

I imagine this will be an interesting discussion.

--
Lionel B. Dyck <><
BMC Software
Product Development Architect, Common Install and Services
10431 Morado Circle, Building 5, Austin, Texas 78759
Office Phone: 512-340-6031 (extension x26031)
Cell Phone: 512-739-3274
E-Mail:  lionel_d...@bmc.com
"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Scott Ford]

Wayne

Yes sir right on the money 

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


> On Dec 6, 2013, at 1:36 PM, Wayne Bickerdike  wrote:
> 
> *d'accord*
> 
> 
>> On Sat, Dec 7, 2013 at 12:55 AM, John Gilmore  wrote:
>> 
>> Google aside, 'ça' has two meanings:
>> 
>> o It is an abbreviation of 'cela', a demonstrative pronoun, as in
>> 'C'est ça!', That's right! .
>> 
>> o It is also an adverb, 'here' or 'hither', as in 'ça et la', here and
>> there.
>> 
>> As Paul Gilmartin all but said, it is always written/printed as 'ça'.
>> If it were written as ''ca', it would be pronounced 'ka', as in
>> 'cabane' , ka'ban, not  'sa', as in 'façade', fa'sahd.
>> 
>> French is a Latin dialect, and the complete text of Pliny the
>> Younger's apothegm:
>> 
>> Errare humanum est, perseverare autem diabolicum.
>> 
>> is relevant here.  To err is human; to persist in it is diabolical.
>> 
>> John Gilmore, Ashland, MA 01721 - USA
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> 
> 
> -- 
> Wayne V. Bickerdike
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Exit interfaces and module attributes (was: Base-less ...)

[Lloyd Fuller]

The problem with using LE programs in exits is the environment in which the 
exits run.  Many run in cross-memory and/or SRB mode so SVCs are not allowed 
and LE functions use SVCs instead of instructions in many cases (i.e., the date 
and time routines).

Lloyd


>
> From: Scott Ford 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Friday, December 6, 2013 1:33 PM
>Subject: Re: Exit interfaces and module attributes (was: Base-less ...)
>  
>
>Gil,
>
>I appreciate what you said. In the perfect world ( wasn't that a Blondie 
>song), the API calls, linkage between languages would be well documented and 
>extensive samples.  But life and code and development sometimes are messy, so 
>experimentation is necessary. I ask questions, because like many of my 
>colleagues I don't have all the answers, especially when I looking at a new 
>design or concept. Times have changed no more PLMs or source to look at ...so 
>here we are...
>
>Scott ford
>www.identityforge.com
>from my IPAD
>
>'Infinite wisdom through infinite means'
>
>
>> On Dec 6, 2013, at 1:22 PM, Paul Gilmartin  wrote:
>> 
>> This thread seems to nave diverged into ASSEMBLER-LIST and
>> IBM-MAIN.  I'm extending the topic.  A contributor said in
>> ASSEMBLER LIST:
>> 
>>    ... I am trying to decide to convert it to baseless or write an
>>    assembler stub and redo the exit in C.
>> 
>> In a perfect universe, a stub would be needless.
>> 
>> About 40 years ago, before I had any OS/360 exposure, an Expert
>> boasted to me that the calling conventions of OS were absolutely
>> homogeneous -- a subroutine in any language could be called from
>> any other language, or as a main program alike.  (I was skeptical --
>> I asked, "LISP?  SNOBOL4?"  My mentor replied, "Of course!")
>> 
>> What have we lost?
>> 
>> With XA, the facility was mostly preserved: CSECTs were marked
>> AMODE 24 or AMODE 31; would be entered in the correct AMODE,
>> and would return to a caller in the caller's mode via BSM.
>> 
>> So, daydream/wishlist item:  It should be made possible to mark
>> a load module as LE-mode so ATTACH or an EXIT interface would
>> seamlessly enter an exit written in LE C (not just Metal C) and the
>> exit return smoothly.
>> 
>> Would Metal C remove the need for an Assembler stub?
>> 
>> -- gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>   
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[Gerhard Postpischil]

On 12/6/2013 1:41 PM, Dyck, Lionel wrote:

Which is better - a BLKSIZE of 3120 with 100 members ranging from 3
to 30 records or that same set of records in a PDS with BLKSIZE of
27920. And similarly what about a PDS with BLKSIZE of 3120 and 100
members ranging from 300 to 9000 records compared to the same set of
records in a PDS with a BLKSIZE of 27920.


I just ran a test on my macro and source libraries. Each has 80 used 
directory blocks.


MACLIB   98 tks with 3120   94 tks with 27920
SOURCE  829 tks with 3120  442 tks with 27920

In practice I've found the optimal block size to be close to half track, 
with one exception (either 3K or 7K record size?), where five block per 
track actually gave better usage.


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Exit interfaces and module attributes (was: Base-less ...)

[Tony Harminc]

On 6 December 2013 13:22, Paul Gilmartin  wrote:
>
> Would Metal C remove the need for an Assembler stub?

In this case, probably. But Metal C is not a general substitute for
assembler language, even though you can have inline assembler
statements. Notably, the compiler has several hard-coded ideas of what
registers it can use, e.g. R3  addresses a literal pool, it assumes
that R13 points to a stack, and it may use R10 and R11 for constants.

Unlike PL/X there appears to be no #PRAGMA or the like to tell the
compiler to stop using a register for a while, so if you have a
non-standard linkage (say BASR R10,R11) you will have some trouble.
(Metal C does have "clobber lists" of registers when using the __asm()
construct, but they are so clunky as to be virtually unusable and
unreadable.)

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[Scott Ford]

Gerhard and Lionel,

How much wasted space is there in the blocks or blksize, slack bytes was the 
old name many moons ago

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


> On Dec 6, 2013, at 3:30 PM, Gerhard Postpischil  wrote:
> 
>> On 12/6/2013 1:41 PM, Dyck, Lionel wrote:
>> Which is better - a BLKSIZE of 3120 with 100 members ranging from 3
>> to 30 records or that same set of records in a PDS with BLKSIZE of
>> 27920. And similarly what about a PDS with BLKSIZE of 3120 and 100
>> members ranging from 300 to 9000 records compared to the same set of
>> records in a PDS with a BLKSIZE of 27920.
> 
> I just ran a test on my macro and source libraries. Each has 80 used 
> directory blocks.
> 
> MACLIB 98 tks with 312094 tks with 27920
> SOURCE  829 tks with 3120  442 tks with 27920
> 
> In practice I've found the optimal block size to be close to half track, with 
> one exception (either 3K or 7K record size?), where five block per track 
> actually gave better usage.
> 
> Gerhard Postpischil
> Bradford, Vermont
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[Gerhard Postpischil]

On 12/6/2013 3:38 PM, Scott Ford wrote:

How much wasted space is there in the blocks or blksize, slack bytes was the 
old name many moons ago


It depends on your definition of "wasted" - both libraries use 80 byte 
records, and some people on this list consider 73-80 wasted (on sequence 
numbers). According to BLK3390, the 27920 block size uses 98.5% of the 
track, whereas 3120 uses 82.6%.


For assembly language, compression of blanks would halve the required space?

Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[Paul Gilmartin]

On Fri, 6 Dec 2013 12:41:39 -0600, Dyck, Lionel wrote:
>
>Having a large a blksize with many small members results in many blocks with 
>wasted space. Having a small blksize with many large members results in 
>unnecessary I/O to read all the blocks of data.
> 
I don't believe the usual access methods will ever write blocks containing
unused space (perhaps null segments with RECFM=VBS?)  But since track
balancing is not routinely performed except by Binder, there's likely to be
an average of BLKSIZE/2 unused space at the end of each track.

On Fri, 6 Dec 2013 15:30:37 -0500, Gerhard Postpischil wrote:
>
>In practice I've found the optimal block size to be close to half track,
>with one exception (either 3K or 7K record size?), where five block per
>track actually gave better usage.
> 
I believe from the 3390 Ref and some trial and error that it's about 7K,
with 7 blocks per track.  And SDB actually selects that number.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Exit interfaces and module attributes (was: Base-less ...)

[Shmuel Metz (Seymour J.)]

In <3143369843874551.wa.paulgboulderaim@listserv.ua.edu>, on
12/06/2013
   at 12:22 PM, Paul Gilmartin  said:

>About 40 years ago, before I had any OS/360 exposure, an Expert
>boasted to me that the calling conventions of OS were absolutely
>homogeneous -- a subroutine in any language could be called from 
>any other language, or as a main program alike.  (I was skeptical 
>-- I asked, "LISP?  SNOBOL4?"  My mentor replied, "Of course!")

Is your expert in the market for a bridge?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[Shmuel Metz (Seymour J.)]

In
,
on 12/06/2013
   at 12:41 PM, "Dyck, Lionel"  said:

>Having a large a blksize with many small members results in many
>blocks with wasted space.

How? The Devil is in the details.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Shmuel Metz (Seymour J.)]

In <32b4040d-954c-4ca0-9c4f-f472f666c...@yahoo.com>, on 12/05/2013
   at 01:38 PM, Scott Ford  said:

>I always thought VMS was *nix like???

>If not what opsys is it similar too or is it's own thang

It's its own thing, although the designers may have picked up some
ideas from the PDP-10 side of the house. There was a Unix for the VAX,
but that has nothing to do with VMS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Shmuel Metz (Seymour J.)]

In
,
on 12/05/2013
   at 11:04 AM, John McKown  said:

>Thanks. I am not any kind of expert, but the "otelnetd" UNIX 
>daemon that I mentioned in a previous post in this thread 
>_seems to me_ to implement this fairly well.

I suspect that Telnet NVT support is required for POSIX and Unix
certification; certainly I can't imagine getting traction in the *ix
community without it.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[Gerhard Postpischil]

On 12/6/2013 3:48 PM, Paul Gilmartin wrote:

I don't believe the usual access methods will ever write blocks
containing unused space (perhaps null segments with RECFM=VBS?)  But
since track balancing is not routinely performed except by Binder,
there's likely to be an average of BLKSIZE/2 unused space at the end
of each track.


I just relinked all of a load module library, and for a block size of 
6160 it used 153 tracks, versus 149 tracks for 27998 size. Most of the 
blocks are control records <= 256 bytes.


But for the common card format libraries, there seems to be relatively 
little waste despite large blocks sizes.


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[Paul Gilmartin]

On Fri, 6 Dec 2013 18:27:39 -0500, Gerhard Postpischil wrote:
>
>I just relinked all of a load module library, and for a block size of
>6160 it used 153 tracks, versus 149 tracks for 27998 size. Most of the
>blocks are control records <= 256 bytes.
>
Load modules are special; Binder is clever.  How about 32760?

>But for the common card format libraries, there seems to be relatively
>little waste despite large blocks sizes.
>
Force a worst case for LRECL=80.  Use BLKSIZE=27920  (I believe that's
the SDB default), then write several files each with 350 records.  Try again
with BLKSIZE=24000 (I'm guessing), then compare.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[DASDBILL2]

We can calculate the wasted space given the block size, average number of 
blocks per track, average number of this, that, and the other thing, but wasted 
space is meaningless and unknowable unless you are using a SLED 3390 which 
means now at least 15, maybe 20-year old disk drives.  With the advent of RAID, 
the interrecord gaps have been virtualized. 
Another consideration is that you want to know which of two alternatives is 
"better".  My answer is that it depends - on what variable you wish to 
optimize, space utilization being only one of many possible variables for which 
you might want to find a "best" value.  Speed of access is another variable, 
and it could mean either elapsed time, average connect time, channel 
utilization, etc.  Elapsed time can usually be minimized by having all blocks 
be the maximum possible size.  Connect time, conversely, is reduced by 
transferring smaller block sizes per I/O request.  But the more I/O requests 
you do, the more CPU time your application will eat up in doing the I/Os.  And 
larger block sizes need more real storage to back the larger buffer sizes 
during each I/O, which impacts the working set size of your application and 
possibly causing other work in the  system to suffer more paging. 
  
Bill Fairchild 
Franklin, TN 

- Original Message -

From: "Scott Ford"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, December 6, 2013 2:38:50 PM 
Subject: Re: Something to Think About - Optimal PDS Blocking 

Gerhard and Lionel, 

How much wasted space is there in the blocks or blksize, slack bytes was the 
old name many moons ago 

Scott ford 
www.identityforge.com 
from my IPAD 

'Infinite wisdom through infinite means' 


> On Dec 6, 2013, at 3:30 PM, Gerhard Postpischil  wrote: 
> 
>> On 12/6/2013 1:41 PM, Dyck, Lionel wrote: 
>> Which is better - a BLKSIZE of 3120 with 100 members ranging from 3 
>> to 30 records or that same set of records in a PDS with BLKSIZE of 
>> 27920. And similarly what about a PDS with BLKSIZE of 3120 and 100 
>> members ranging from 300 to 9000 records compared to the same set of 
>> records in a PDS with a BLKSIZE of 27920. 
> 
> I just ran a test on my macro and source libraries. Each has 80 used 
> directory blocks. 
> 
> MACLIB     98 tks with 3120    94 tks with 27920 
> SOURCE  829 tks with 3120      442 tks with 27920 
> 
> In practice I've found the optimal block size to be close to half track, with 
> one exception (either 3K or 7K record size?), where five block per track 
> actually gave better usage. 
> 
> Gerhard Postpischil 
> Bradford, Vermont 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[DASDBILL2]

Upon re-reading the original post, I see yet another variable - the  use of the 
PDS.  He did not say for a load library, nor did he say PDS or PDSE.  He said 
PDS, and then was vague about the planned use of the PDS, which could be for a 
load library, production data, or metadata used for a homegrown index into a 
much larger, different file. 

Bill Fairchild 

- Original Message -

From: "DASDBILL2"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, December 6, 2013 7:56:56 PM 
Subject: Re: Something to Think About - Optimal PDS Blocking 

We can calculate the wasted space given the block size, average number of 
blocks per track, average number of this, that, and the other thing, but wasted 
space is meaningless and unknowable unless you are using a SLED 3390 which 
means now at least 15, maybe 20-year old disk drives.  With the advent of RAID, 
the interrecord gaps have been virtualized. 
Another consideration is that you want to know which of two alternatives is 
"better".  My answer is that it depends - on what variable you wish to 
optimize, space utilization being only one of many possible variables for which 
you might want to find a "best" value.  Speed of access is another variable, 
and it could mean either elapsed time, average connect time, channel 
utilization, etc.  Elapsed time can usually be minimized by having all blocks 
be the maximum possible size.  Connect time, conversely, is reduced by 
transferring smaller block sizes per I/O request.  But the more I/O requests 
you do, the more CPU time your application will eat up in doing the I/Os.  And 
larger block sizes need more real storage to back the larger buffer sizes 
during each I/O, which impacts the working set size of your application and 
possibly causing other work in the  system to suffer more paging. 
  
Bill Fairchild 
Franklin, TN 

- Original Message - 

From: "Scott Ford"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, December 6, 2013 2:38:50 PM 
Subject: Re: Something to Think About - Optimal PDS Blocking 

Gerhard and Lionel, 

How much wasted space is there in the blocks or blksize, slack bytes was the 
old name many moons ago 

Scott ford 
www.identityforge.com 
from my IPAD 

'Infinite wisdom through infinite means' 


> On Dec 6, 2013, at 3:30 PM, Gerhard Postpischil  wrote: 
> 
>> On 12/6/2013 1:41 PM, Dyck, Lionel wrote: 
>> Which is better - a BLKSIZE of 3120 with 100 members ranging from 3 
>> to 30 records or that same set of records in a PDS with BLKSIZE of 
>> 27920. And similarly what about a PDS with BLKSIZE of 3120 and 100 
>> members ranging from 300 to 9000 records compared to the same set of 
>> records in a PDS with a BLKSIZE of 27920. 
> 
> I just ran a test on my macro and source libraries. Each has 80 used 
> directory blocks. 
> 
> MACLIB     98 tks with 3120    94 tks with 27920 
> SOURCE  829 tks with 3120      442 tks with 27920 
> 
> In practice I've found the optimal block size to be close to half track, with 
> one exception (either 3K or 7K record size?), where five block per track 
> actually gave better usage. 
> 
> Gerhard Postpischil 
> Bradford, Vermont 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[Ed Finnell]

With modern DASD I wouldn't put much effort in to trying to find out.  
Unless it's really horrid, caching and buffering will pave it over.
 
 
In a message dated 12/6/2013 8:05:10 P.M. Central Standard Time,  
dasdbi...@comcast.net writes:

library,  nor did he say PDS or PDSE.  He said PDS, and then was vague 
about the  planned use of the PDS, which could be for a load library, 
production 
data, or  metadata used for a homegrown index into a much larger, different 
 file. 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something to Think About - Optimal PDS Blocking

[Robert A. Rosenberg]

At 12:41 -0600 on 12/06/2013, Dyck, Lionel wrote about Something to 
Think About - Optimal PDS Blocking:


We all know about system determined blksize and there have been 
rules of thumb for decades about the correct/optimal blksize to use 
for each type of PDS.


My question is what is the optimal blksize for a PDS based on the 
member sizes?


Having a large a blksize with many small members results in many 
blocks with wasted space. Having a small blksize with many large 
members results in unnecessary I/O to read all the blocks of data.


The various tools available to provide a best estimate at optimal 
blksize (e.g. trkcalc, blkdisk, blk3390) and even SDB all provide a 
best estimate without having any awareness of the planned, or 
existing, contents of the PDS.


Which is better - a BLKSIZE of 3120 with 100 members ranging from 3 
to 30 records or that same set of records in a PDS with BLKSIZE of 
27920. And similarly what about a PDS with BLKSIZE of 3120 and 100 
members ranging from 300 to 9000 records compared to the same set of 
records in a PDS with a BLKSIZE of 27920.


I imagine this will be an interesting discussion.


I feel that part of the problem with answering this issue is that IMO 
FB support is BAD (Broken As Designed). FB files (as opposed to FBS 
files) are allowed to have imbedded short blocks. If I write a VBS 
file to DASD, the write support has the smarts to check how much room 
is left on the current track and to fill it up by writing a short 
segment before writing the rest to the next track(s). Why when I 
declare the PDS as FB (but not FBS) can the support figure out the 
remaining room on the track and write two blocks (one the size of the 
remaining room and the second for the the rest of the BLKSIZE)? If 
this was done this would be a non-issue since if a full sized block 
would not fit on the track 2 shorter blocks would be written. The 
check for remaining room is I assume done for the first block of a 
member since the number of BLKSIZE records that fit on a track is not 
necessarily the same as for the track with the first block of a 
member due to the prior member's EOM record taking up space.



--
Lionel B. Dyck <><
BMC Software
Product Development Architect, Common Install and Services
10431 Morado Circle, Building 5, Austin, Texas 78759
Office Phone: 512-340-6031 (extension x26031)
Cell Phone: 512-739-3274
E-Mail:  lionel_d...@bmc.com
"Worry more about your character than your reputation.  Character is 
what you are, reputation merely what others think you are." - John 
Wooden



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN