Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc

[Shane Ginnane]

On Sat, 7 Sep 2013 21:52:07 -0400, John Gilmore wrote:

>Qua sysprog, I am sure thjat you are aware that PDSEs are problematic
>early in an IPL process; but none of these problems obtains for COBOL
>APs.

Very late to this, so sorry if my concerns have been answered  earlier.
What about shops with a ring of monoplexes ?. The sysplex scope is each 
individual monoplex - but the sharing boundary is the larger GRSplex. Latch 
contention - particularly PDSE latches - are a PITA.

>Tom Ross and his colleagues are to be applauded for having taken  this
>step.  It was long, long overdue; and COBOL shops are now being
>dragged, kicking and screaming as usual, into the last lustrum of the
>20th century

H - wishful thinking I suspect. There are other issues to be addressed 
first - I would counter that this may well slow the adoption of 5.1 in more 
than a few shops.

Shane ...

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

Re: RACF Database protection

[Shmuel Metz (Seymour J.)]

In
<0539133098161601.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>,
on 09/05/2013
   at 03:31 AM, Elardus Engelbrecht 
said:

>You can wish, but big blue wants backward compatibility,

How is that an obstacle? If they do it, I'm sure that there will be a
switch to enable the new algorithm and that, once enabled, the new
algorithm will only be used incrementally.
 
-- 
 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: Sortlessness?

[Shmuel Metz (Seymour J.)]

In <5227bf91.7010...@aim.com>, on 09/04/2013
   at 05:17 PM, Paul Gilmartin  said:

>> On 1 September 2013 00:51, Paul Gilmartin wrote:

>>> LE gave me WAD with a rationale so outrageous that I gave up in
>>> disgust, making no effort to escalate.

An outrageous rationale is precisely when there is the best case to
escalate.

>> Isn't it a POSIX violation to produce incorrect collation results for
>> a locale? Not, I suppose, that that's stopped them before.

Yes. If you can find suitable contacts in the UNIX® community[1],
getting that in the compliance test suite would guaranty that IBM
fixes it.

[1] Presumably either POSIX or The Open Group would do.
 
-- 
 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: UNIT=SEP still alive (?)

[Shmuel Metz (Seymour J.)]

In , on 09/04/2013
   at 09:55 PM, "Robert A. Rosenberg"  said:

>Except for one MAJOR difference - PASS will leave the tape mounted 
>(although it might rewind it) while KEEP will unload the tape 

Not if you specify RETAIN. Unfortunately, there's no text unit for
RETAIN, at least prior to z/OS V2R1, and probably not there either.
 
-- 
 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: Searching for a SUBMIT and WRITER tool

[Shmuel Metz (Seymour J.)]

In
<2091430682-1378385115-cardhu_decombobulator_blackberry.rim.net-518132742-@b4.c1.bise6.blackberry>,
on 09/05/2013
   at 12:45 PM, Ted MacNEIL  said:

>Who are you to determine the needs of the user (whom you are
>[supposedly] supporting).

There's only one user at your shop? Or you only support one of them?
Who are you to tell him not to enforce policies set by his management?
 
-- 
 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: Destination z: Strolling Down Memory (Core) Lane

[Shmuel Metz (Seymour J.)]

In <5228c8c4.7020...@gabegold.com>, on 09/05/2013
   at 02:09 PM, Gabe Goldberg  said:

>Strolling Down Memory (Core) Lane

Core? On my first machine, main memory was drum.
 
-- 
 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: OT: Obscurity Is Not Security... Or Is It?

[Shmuel Metz (Seymour J.)]

In <522b1cbc.1070...@bremultibank.com.pl>, on 09/07/2013
   at 02:31 PM, "R.S."  said:

>Sometimes you know (or at least you feel) that your system is not 
>bullteproof. In such case you could do the following: a) make your
>system bullteproof. WRONG. Usually you would already do it if you
>could. But you Couldn't.

Nonsense. There are lots of reasons that a system still has known
security holes, and the reasons are rarely technical, at least not
since the advent of MVS. If you become aware of a security exposure,
get management signoff and close it.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: Searching for a SUBMIT and WRITER tool

[Shmuel Metz (Seymour J.)]

In <3044928827063159.wa.paulgboulderaim@listserv.ua.edu>, on
09/05/2013
   at 08:30 AM, Paul Gilmartin  said:

>Wouldn't it be nice to be able not to ABEND, but to checkpoint the
>job when it reaches the limlt and allow the user to insert more 
>coins and continue?

Submit a requirement; it sounds like a good idea.
 
-- 
 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: timezone_name?

[Shmuel Metz (Seymour J.)]

In <011401ceaa8d$7b6acab0$72406010$@mcn.org>, on 09/05/2013
   at 04:13 PM, Charles Mills  said:

>EST5EDT

Due to parsing ambiguity, that doesn't tell you when to switch.
 
-- 
 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 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.

[Shmuel Metz (Seymour J.)]

In <0810432924290538.wa.dbohnaegonusa@listserv.ua.edu>, on
09/06/2013
   at 08:16 AM, "Bohn, Dale"  said:

>The non-loaded class are only supported in the PM3(?) load modules
>which the binder will only put into a PDSE.

Don't confuse load modules with program objects. The BINDER will only
create a load module in a PDS and will only create a program object in
a PDSE. The formats are pretty much unrelated. I'm not aware of any
new load module features added by the BINDER; in particular, there are
no long names and no classes, hence the need for the output of newer
compilers to go into program objects.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.

[Shmuel Metz (Seymour J.)]

In
<4ee2851a2279b94cb70cd69b17410609ae51c...@s1flokydce2kx01.dm0001.info53.com>,
on 09/06/2013
   at 12:01 PM, "Jousma, David"  said:

>A program object is a new style GOOF executable that is the output 
>from the binder when binding an object module from Enterprise 
>COBOL V5.1.

No. A program object is an old[1] style executable module[2] that is
the output  from the binder when creating an executable module in a
PDSE. What is new with V5.1 is that the creation of load modules in a
PDS is no longer supported.

[1] But not as old as a load module.

[2] Unrelated to GOFF, which is the format for object modules

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc

[Shmuel Metz (Seymour J.)]

In , on 09/07/2013
   at 09:22 AM, Tom Ross  said:

>No, the COBOL Migration Guide is correct, all COBOL programs 
>produce GOFF output with COBOL V5, so after Binding you will have 
>a program object and it must reside in a PDSE.

It's not the use of GOFF per se that requires program objects, it's
the use of GOFF features that aren't supported in load modules.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: timezone_name?

[Mike Schwab]

On Sun, Sep 8, 2013 at 5:52 AM, Shmuel Metz (Seymour J.)
 wrote:
> In <011401ceaa8d$7b6acab0$72406010$@mcn.org>, on 09/05/2013
>at 04:13 PM, Charles Mills  said:
>
>>EST5EDT
>
> Due to parsing ambiguity, that doesn't tell you when to switch.
>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT

http://en.wikipedia.org/wiki/Tz_database does tell you when to switch.
 And when to add or subtract leap seconds.

-- 
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: timezone_name?

[Mike Schwab]

http://en.wikipedia.org/wiki/Tz_database does tell you when to switch.
 And when to add or subtract leap seconds.

On Sun, Sep 8, 2013 at 5:52 AM, Shmuel Metz (Seymour J.)
 wrote:
> In <011401ceaa8d$7b6acab0$72406010$@mcn.org>, on 09/05/2013
>at 04:13 PM, Charles Mills  said:
>
>>EST5EDT
>
> Due to parsing ambiguity, that doesn't tell you when to switch.
>
> --
>  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



-- 
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: timezone_name?

[Mike Schwab]

http://en.wikipedia.org/wiki/Tz_database Does tell you the offset,
when to switch.
 And when to add or subtract leap seconds.

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

Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc

[John Gilmore]

Shane's surmise that the PDSE requirement for COBOL 5.1 executables
will slow its adoption in many shops is certainly correct.  All such
requirements do so.

Where Shane and I differ, and I suspect that this difference is
visceral, is that I am radically impatient with the "conservatism" of
these shops, which is making them irrelevant, and he is [legitimately]
preoccupied with their current, detailed, operational problems.

I do not, of course, deny that there are such problems.  They are
always with us.   Nirvana will not obtain when the current batch have
been resolved.  They will be succeeded by others of much the same
sort.  The existence of a set of these problems, whatever its current
makeup may be, is not, however, an argument for stasis.

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: RACF Database protection

[Elardus Engelbrecht]

Shmuel Metz (Seymour J.) wrote:

>>You can wish, but big blue wants backward compatibility,

>How is that an obstacle? If they do it, I'm sure that there will be a switch 
>to enable the new algorithm and that, once enabled, the new algorithm will 
>only be used incrementally.

Agreed, Shmuel. Thanks for your comment. I will be the last person to disagree 
with you. ;-D

They have already done that 'switch'. Read the RACF books about choice of 
password [1] encryption. But still, they will only do that if backward 
compatibility is NOT compromised. If backward compatibility could be 
compromised, they will warn you, just like they did with some product features. 
You remember that phasing out of ISAM? ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - technically, for RACF, not exactly passwords are encrypted, but userids. 
But I used word 'password' to make a point.

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

Re: timezone_name?

[Paul Gilmartin]

On Sun, 8 Sep 2013 08:04:35 -0500, Mike Schwab wrote:

>http://en.wikipedia.org/wiki/Tz_database Does tell you the offset,
>when to switch.
> And when to add or subtract leap seconds.
> 
z/OS is the only OS of which I know that accommodates leap
seconds in its hardware clock (are there others?)

I believe (there's no documentation and IBM has rejected my
RCF that it be provided; Peter Relson (IIRC) has suggested that
I must appeal to "common knowledge" for the information)
that STCKCONV, the IBM utility for converting historical (E)TOD
values such as might appear in log files, is ignorant of the
calendar of historical leap seconds.

And I believe z/OS does not employ Tz_database for setting
CVTLSO.  Do other OSes employ the leap seconds part of the
Tz_database, perhaps through NTP client?

-- gil

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

Re: Destination z: Strolling Down Memory (Core) Lane

[Jon Perryman]

WOW. How did it use drum as main memmory? Did it have like 1K of real memory 
and have hardware to move from drum upon address resolution? Or is drum a 
similar architecture to ram?

Jon Perryman.




>
> From: Shmuel Metz (Seymour J.) 
>
>
>
>   at 02:09 PM, Gabe Goldberg  said:
>
>>Strolling Down Memory (Core) Lane
>
>Core? On my first machine, main memory was drum.
>

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

Re: Destination z: Strolling Down Memory (Core) Lane

[Paul Gilmartin]

On Sun, 8 Sep 2013 09:58:29 -0700, Jon Perryman wrote:

>WOW. How did it use drum as main memmory? Did it have like 1K of real memory 
>and have hardware to move from drum upon address resolution? Or is drum a 
>similar architecture to ram?
>
Nope.  None of the above.  The drum was "real".  From:

http://en.wikipedia.org/wiki/IBM_650#Hardware

The rotating drum memory provided 2,000 signed 10-digit words of memory ...,
which is approximately 8.5 KB in today's units.
...
A word could not be accessed until its location on the drum surface passed 
under the
   read/write heads during rotation (rotating at 12,500 rpm, the non-optimized 
average
access time was 2.5 ms). ...

That's ms, not μs.

Programs could be optimized by placing instructions around the drum based 
on the
expected execution time of the previous instruction.

-- gil

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

Re: DASD space management

[Scott Barry]

Also consider WPS as a SAS alternative which is MXG-certified.

http://www.teamwpc.co.uk/products/wps 

Scott Barry
SBBWorks, Inc.

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

Re: OT: Obscurity Is Not Security... Or Is It?

[Scott Ford]

So I guess you guys haven't worked on Wall Street, three + firewalls in and out 
of an environment. Complex firewall rules, RACF or ACF2 or Top-Secret rules.

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Sep 7, 2013, at 8:58 PM, "Shmuel Metz (Seymour J.)"  
wrote:

> In <522b1cbc.1070...@bremultibank.com.pl>, on 09/07/2013
>   at 02:31 PM, "R.S."  said:
> 
>> Sometimes you know (or at least you feel) that your system is not 
>> bullteproof. In such case you could do the following: a) make your
>> system bullteproof. WRONG. Usually you would already do it if you
>> could. But you Couldn't.
> 
> Nonsense. There are lots of reasons that a system still has known
> security holes, and the reasons are rarely technical, at least not
> since the advent of MVS. If you become aware of a security exposure,
> get management signoff and close it.
> 
> -- 
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> Atid/2
> 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

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

Re: OT: Obscurity Is Not Security... Or Is It?

[Scott Ford]

Nothing is per se bulletproof, system wise IMHO . It's the same as 100% uptime.
You can hit about 99%, been there using Fiber Options ,Sonet Rings, but the 
last 1 % is difficult if not impossible without a lot of cash

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Sep 8, 2013, at 2:46 PM, Scott Ford  wrote:

> So I guess you guys haven't worked on Wall Street, three + firewalls in and 
> out of an environment. Complex firewall rules, RACF or ACF2 or Top-Secret 
> rules.
> 
> Scott ford
> www.identityforge.com
> from my IPAD
> 
> 'Infinite wisdom through infinite means'
> 
> 
> On Sep 7, 2013, at 8:58 PM, "Shmuel Metz (Seymour J.)" 
>  wrote:
> 
>> In <522b1cbc.1070...@bremultibank.com.pl>, on 09/07/2013
>>  at 02:31 PM, "R.S."  said:
>> 
>>> Sometimes you know (or at least you feel) that your system is not 
>>> bullteproof. In such case you could do the following: a) make your
>>> system bullteproof. WRONG. Usually you would already do it if you
>>> could. But you Couldn't.
>> 
>> Nonsense. There are lots of reasons that a system still has known
>> security holes, and the reasons are rarely technical, at least not
>> since the advent of MVS. If you become aware of a security exposure,
>> get management signoff and close it.
>> 
>> -- 
>>Shmuel (Seymour J.) Metz, SysProg and JOAT
>>Atid/2
>> 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
> 
> --
> 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: OT: Obscurity Is Not Security... Or Is It?

[R.S.]

W dniu 2013-09-08 20:46, Scott Ford pisze:

So I guess you guys haven't worked on Wall Street, three + firewalls in and out 
of an environment. Complex firewall rules, RACF or ACF2 or Top-Secret rules.


...and your point is?

--
Radoslaw Skorupka
Lodz, Poland






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


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



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

Re: OT: Obscurity Is Not Security... Or Is It?

[Scott Ford]

You can secure the environment one is responsible for with correct knowledge 
and funding

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Sep 8, 2013, at 3:22 PM, "R.S."  wrote:

> W dniu 2013-09-08 20:46, Scott Ford pisze:
>> So I guess you guys haven't worked on Wall Street, three + firewalls in and 
>> out of an environment. Complex firewall rules, RACF or ACF2 or Top-Secret 
>> rules.
> ...and your point is?
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> --
> 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 authorised 
> 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. 
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
> +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
> Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
> Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci 
> wpacony) wynosi 168.555.904 zotych.
> 
> 
> --
> 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: OT: Obscurity Is Not Security... Or Is It?

[R.S.]

W dniu 2013-09-08 21:34, Scott Ford pisze:

You can secure the environment one is responsible for with correct knowledge 
and funding


...unless the environment you have is insecure by design and cannot be 
secured despite of budget used.
You can make the strongbox (safe) insecure by stupid mistakes, but you 
cannot make secure scout tent, even if can afford jumbo jet.

Of course this discussion is off topic.

BTW: I feel that some of responders did read only the title, while the 
article presented very specific flavor of obscurity. I would call it 
smart obscurity. In fact this is slightly similar to encryption. Is 
encryption safe? It depends on your opinion. Everyone who intercepted 
our communication can decrypt it ...after many years - or just withing 
two seconds, because first key tried was good. Stroke of luck. However 
we use encryption, because *we cannot* use real security. We cannot make 
our wires secure.
Does your Wall-Street companies use SSL? Why? Because they *cannot* make 
the communication free of interception.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorised 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. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



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

Re: timezone_name?

[John Gilmore]

I'm not sure I understand Paul's last post.

z/OS does keep the current leap-second count at hand.  This value
changes at most twice a year, at the end of June and at the end of
December; and ample advance notice, at least six months' notice under
BIPM's rules, is given of an impending increment or decrement.

Consulting a real-time data base in these circumstances seems to me to
be overkill.  Why not update a static table?

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: OT: Obscurity Is Not Security... Or Is It?

[Scott Ford]

R.S.

Agreed ...but security is difficult nowdays with hackers on the 'Net' ...
The problem when I worked on Wall Street was the time to implement changes 
Too too long because of security, it's like traveling nowdays by Air..
Security has to have a better solution we deal with AES128 encryption and 
decryption,
And Banking so you you know kind a where we are, we have to be concerned about 
secure connections.

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Sep 8, 2013, at 4:13 PM, "R.S."  wrote:

> W dniu 2013-09-08 21:34, Scott Ford pisze:
>> You can secure the environment one is responsible for with correct knowledge 
>> and funding
>> 
>> 
> ...unless the environment you have is insecure by design and cannot be 
> secured despite of budget used.
> You can make the strongbox (safe) insecure by stupid mistakes, but you cannot 
> make secure scout tent, even if can afford jumbo jet.
> Of course this discussion is off topic.
> 
> BTW: I feel that some of responders did read only the title, while the 
> article presented very specific flavor of obscurity. I would call it smart 
> obscurity. In fact this is slightly similar to encryption. Is encryption 
> safe? It depends on your opinion. Everyone who intercepted our communication 
> can decrypt it ...after many years - or just withing two seconds, because 
> first key tried was good. Stroke of luck. However we use encryption, because 
> *we cannot* use real security. We cannot make our wires secure.
> Does your Wall-Street companies use SSL? Why? Because they *cannot* make the 
> communication free of interception.
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> --
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być 
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś 
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej 
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, 
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie 
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, 
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale 
> usunąć tę wiadomość włączając 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 authorised 
> 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. 
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
> +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
> Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
> Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości 
> wpłacony) wynosi 168.555.904 złotych.
> 
> 
> --
> 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: Comp-3 data defintion

[Clark Morris]

On 6 Sep 2013 08:22:58 -0700, in bit.listserv.ibm-main you wrote:

>Hello
>
>We have a job in which the input file that is comming has one on the field 
>(Location Number) is defined as X(4). This file is comming from a different 
>system.
>
>Now here in our programs we are modifying the this field to 5 bytes from the 
>orginal 4 bytes. We are putting transformation step previous to this step and 
>expanding to 5 bytes .  We will be removing this process once the other system 
>sends the file with a 5 bye customer number.
>
>So now the issue is in some files the data is stored as s9(04) comp-3 here we 
>are planning to make as s9(05) comp-3.  Do we need to apply transformations 
>here ? both the data defintions occupy 3 bytes
>
>Is there any chance of data getting corrupted ? if data transformations to be 
>applied then how this can be done ? assume that the loaction number starts in 
>the file from 10'th position .
>
Where in the 4 byte field is the 3 byte (PIC S9(4)
COMP-3/PACKED-DECIMAL) data stored and where should it be stored in
the new 5 byte field?  The answer to that question will determine what
needs to be done.

Clark Morris 
>
>Thanks,
>Ron T
>

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

Re: Destination z: Strolling Down Memory (Core) Lane

[Shmuel Metz (Seymour J.)]

In <1378659509.50854.yahoomail...@web181006.mail.ne1.yahoo.com>, on
09/08/2013
   at 09:58 AM, Jon Perryman  said:

>WOW. How did it use drum as main memmory?

Same way as any other drum computer.

>Did it have like 1K of real memory

A drum *is* real memory. In this case, 2K 10 digit words.

>Or is drum a similar architecture to ram?

If your RAM is in a centrifuge.

Every drum computer that I know of had a head per track, so access
time was rotational delay.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: timezone_name?

[Shmuel Metz (Seymour J.)]

In
,
on 09/08/2013
   at 08:02 AM, Mike Schwab  said:

>http://en.wikipedia.org/wiki/Tz_database does tell you when to
>switch.

The Devil is in the details. The string "EST5EDT" doesn't have enough
information to unambiguously indicate the country and zone.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: Comp-3 data defintion

[John Gilmore]

There are two issues here that need to be disentangled.

Storage representations of packed-decimal values always contain an odd
number of digits, viz., one of 1, 3, 5, . . . , 2i - 1, . . . , 31 for
i - 1, 2, 3, . . . , 16.

If now in COBOL you declare a number of digits d for a computational-3
value, storage for floor[(d+1)/2] bytes is always allocated, and the
leftmost, high-order digit participates in all arithmetic operations.

You can arrange to ensure that the compiler will force this leftmost
packed-decimal digit to be 0 in most circumstances.  Doing so will
involve the use of a good many extra instructions, and it is always
and everywhere a bad practice.

The use of an even number of digits in the declaration of a
packed-decimal/computational-3 value is in fact an all but infallible
diagnostic of incompetence.

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: timezone_name?

[Paul Gilmartin]

On Sun, 8 Sep 2013 16:22:53 -0400, John Gilmore wrote:

>I'm not sure I understand Paul's last post.
>
>z/OS does keep the current leap-second count at hand.  This value
>changes at most twice a year, at the end of June and at the end of
>December; and ample advance notice, at least six months' notice under
>BIPM's rules, is given of an impending increment or decrement.
> 
I thought it was four months.  Whatever.  But it does not keep a record
of the change history, necessary for converting archival timestamps,
assuming they were recorded in (E)TOD format.

>Consulting a real-time data base in these circumstances seems to me to
>be overkill.  Why not update a static table?
>
Agreed.  Consider the static table to be a cache of the data base, updated
as necessary, which is seldom.  In fact, I think ICANN and IERS supply
only flat files, to be formatted as necessary.

The multiplicity rises for civil time zones, but a static table in (virtual)
memory, suitably indexed, may still be the right approach.  UNIX likes
to use filesystem directories as pseudo-KSDS indices.

-- gil

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

Currently dispatched TCB in SRB mode

[Peter Relson]

>CVTPCCAT->PCCAVT->PCCA->PSA

If you are not serialized properly, any reference to the PCCA can blow up 
as the PCCA may be freed if the processor is taken offline.

If you are referencing "your" PSA, PCCA->PSA is incorrect (hint: look up 
"reverse prefixing"). 

Peter Relson
z/OS Core Technology Design

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

Re: Currently dispatched TCB in SRB mode

[Micheal Butz]

Do I need to hold any locks ?

Sent from my iPhone

On Sep 8, 2013, at 9:35 PM, Peter Relson  wrote:

>> CVTPCCAT->PCCAVT->PCCA->PSA
> 
> If you are not serialized properly, any reference to the PCCA can blow up 
> as the PCCA may be freed if the processor is taken offline.
> 
> If you are referencing "your" PSA, PCCA->PSA is incorrect (hint: look up 
> "reverse prefixing"). 
> 
> Peter Relson
> z/OS Core Technology Design
> 
> --
> 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: OT: Obscurity Is Not Security... Or Is It?

[Jon Perryman]

No matter how much knowledge and money you have available, you can't be 100% 
secure (we still have APF). You can only secure known exposures as well as the 
technologie permits and reduce area's of risk. While z/OS can be extremely 
secure, you don't review IBM's code for exposures. How about vendor code? Do 
you upgrade products and know they did not introduce an exposure. Are the 
employee's 100% infallible and trustworthy.

Security is by nature obscurity. There is a saying that the solution to the 
problem only changes the problem. As others have said, this is a question about 
money, willingness and perseverance to find a hole. Userid's, passwords and 
securid are obscure (unlikely but possible to guess). Encryption is unlikely 
but possible to break given time and willpower (they say CIA can crack 256 byte 
keys). RACF protects datasets from some users but not others. APF libraries are 
limited and access restricted but some users must have access. Sysprogs get 
more access to system datasets when installing new releases and updates. We 
consider these to be secure but there are ways you can get at them with luck, 
persistence and willpower. 

Jon Perryman.




>
> From: Scott Ford 
>
>
>
>You can secure the environment one is responsible for with correct knowledge 
>and funding
>

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

Re: Currently dispatched TCB in SRB mode

[Jon Perryman]

Data area's says that serialization is disablement. Does  this mean you need to 
run disabled or lock the CPU associated with the PCCA in question?

Jon Perryman.


>
> From: Micheal Butz 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Sunday, September 8, 2013 7:06 PM
>Subject: Re: Currently dispatched TCB in SRB mode
> 
>
>Do I need to hold any locks ?
>
>On Sep 8, 2013, at 9:35 PM, Peter Relson  wrote:
>
>>> CVTPCCAT->PCCAVT->PCCA->PSA
>> 
>> If you are not serialized properly, any reference to the PCCA can blow up 
>> as the PCCA may be freed if the processor is taken offline.
>> 
>> If you are referencing "your" PSA, PCCA->PSA is incorrect (hint: look up 
>> "reverse prefixing"). 
>

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

Teletypewriter Model 33

[Quasar Chunawala]

Hi everyone,

Today, the mainframe staff in any enterprise work on PC running special
software(the terminal emulator) to connect to the *mainframe server* over
the company intranet. But, back in the 1960's, when mainframes were young,
what were some of input devices? Has anyone typed TSO or compiled programs
on a tele-typewriter model 33? What was it like to work on a key-punch
machine? How was the experience? I suppose, 3278 terminals were introduced
much later by IBM.

Quasar.
http://in.linkedin.com/pub/quasar-chunawala/20/164/133/

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