Re: What crashing COBOL systems reveal about applications maintenance -- GCN

2020-05-13 Thread Wayne Bickerdike
We're going through the COBOL 6 compile exercise, on a Z13. The only
hiccups have been source control and the odd JCL error.

One job fell over in a link edit because a module wasn't found. It's been
nearly 15 years since I worked with this system but somehow I remembered
this module. Turns out it's an object module that was compiled using a C
compiler that we never licenced. At the time, I thought we might get the
Dignus C compiler. It never happened. So all these years later we have a
module, that does some primitive encryption, written in C, author unknown.
Fortunately, it's only used in 3 programs. Not the fault of COBOL again.

It's impressive that not much has been misplaced in over 7,000 source
members and other pieces such as BMS maps.

I'm keen to see how the new objects perform too.

On Thu, May 14, 2020 at 11:15 AM Steve Thompson  wrote:

> I have z14 on the brain. I meant z12s.
>
> On 5/13/20 9:10 PM, Clark Morris wrote:
> > [Default] On 13 May 2020 16:56:58 -0700, in bit.listserv.ibm-main
> > ste...@copper.net (Steve Thompson) wrote:
> >
> >> Suppose that they took a group of programmers and got the production
> online programs to all compile with COBOL 6.2 and OPT(1). Would they see a
> significant reduction in MSUs?  Assuming they are running on z14s minimally?
> >
> > Is it likely in most environments that both the primary and fallback
> > computers (disaster recovery) are z14 or more recent?
> >
> > Clark Morris
> >>
> >> And from that, would they actually be able to do more transactions per
> hour?
> >>
> >> Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr.
> Expct mistaks
> >>
> >>
> >>> On May 13, 2020, at 7:45 PM, Seymour J Metz  wrote:
> >>>
> >>> ?Conspicuously missing from the coverage is any evidence of delays or
> outages attributable to COBOL code running on mainframes. So far the
> stories I've seen turn out to relate to web servers or manual processing,
> not to the back end. Yeah, there could be issues with, e.g., CICS
> transactions written in COBOL, but none of the stories provide any reason
> to believe that to be the case.
> >>>
> >>> More disturbing is the assumption that if they train hordes of COBOL
> programmers and bring all of the applications written in COBOL up to date,
> their troubles will be over. The elephant in the room is all of the code in
> other languages that has also been allowed to languish. It *all* needs to
> be documented and brought up to snuff.
> >>>
> >>>
> >>> --
> >>> Shmuel (Seymour J.) Metz
> >>> http://mason.gmu.edu/~smetz3
> >>>
> >>> 
> >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Mark Regan [marktre...@gmail.com]
> >>> Sent: Wednesday, May 13, 2020 12:21 PM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: What crashing COBOL systems reveal about applications
> maintenance -- GCN
> >>>
> >>>
> https://secure-web.cisco.com/1Ck2hssvPisqB8qyqrPsKlWMSh6SVj36qT95iEGNsvW41QGGjEH5TGYkmfjBEBCwAqsZp1UH2qlJxAPV-nlun5Dg56JO8lyf2QqkfAQDmic0ch6e5uj8J9A-Q3B3We8shuckCRr_XeQmGMDhXgd8TQyRlLdXH9bKy-iCiUCWHj2Kqen8MgwZNhQmpmPDXCZynS12e9_NREBCyJ-ImKut7vZYA4mccK38-ps5r3DJciC05kNl8kmdPhUg60gd1zZz7JURnW9weaJQKKDRSp57OBFh-n49E04rQSKCcaRjfOb7cGMU1n6iqgjTNOpmxmuPIjDr4aGw9aUMm9k3V6bRy75OJLSewcdQoYLb3wcGP1Iff-nYxUbFk8wp8l3lc_AhRdjTQ-059TNEsAQTLJUnMUEkSHuyT9PtOAgQrQdm_g-sdoO8Y415VmGflAy_9xBgfqdVJiOoYQb3UbkX7P6tc_A/https%3A%2F%2Fgcn.com%2Farticles%2F2020%2F05%2F12%2Fkeeping-mainframes-up-to-date.aspx%3Fm%3D1
> >>>
> >>> --
> >>> 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
> >
>
> --
> 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: An older device query - still using??

2020-05-13 Thread Tony Thigpen
The 3540 was the reader/punch that was to replace the card reader/punch 
system. Which it did at both my college (while I was there) and at my 
first job (where it replaced the 96 column card system) just before I 
got there.


The 3740 and 3742 were the replacement for the card punch machine. They 
were highly programmable. You could set up programs where some 
characters "punched" as packed decimal and other characters were punched 
as display characters. It would also sum-check fields in a single record 
and automatically punch final "sums records".


The 3540 had a AWSOMA:  Optical Media AttachTOC that contained a VOL1 
record and multiple HDR1 records which supported multiple files. It had 
tracks and records. I am fuzzy, but I think it supported different 
record lengths (set in the HDR1 for each file). I know you could punch 
both 80 and 96 (in separate files).


The VTOC design was also used in the Optical Media Attach Feature, which 
was actually 'emulated' on the P360/P390 in the AWSOMA dirver.


(All "facts" subject to dropped memory bits due to old age.)

Tony Thigpen

R.S. wrote on 5/13/20 6:59 PM:

I just checked bitsavers and found some information about 3540
1. Capacity - it depends. There were several types and subtypes, and 
sub-subtypes of diskettes. Approximately 256kB to 1,2 MB, however 3540 
used only those low capacity. (details available on request)

2. Feeding media - automatically, not manually.
3. There were two types of 3540, single and double drive.
4. The purpose was to deliver data from keypunch (wrong!) data entry 
stations. At the times before CRT screens became popular.


However still I have no idea about system support. How to write data on 
diskette, how to read from diskette, how to recognize volume ID, etc.

No, I'm not going to use it, but I'm just curious.



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


Re: An older device query - still using??

2020-05-13 Thread Seymour J Metz
It was in the era when IBM was talking about cardleds systems. 


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Attila Fogarasi [fogar...@gmail.com]
Sent: Wednesday, May 13, 2020 9:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

The 3540 was the diskette part of the 3740 data entry workstation
(developed by GSD to replace keypunch and able to connect to all the FS
systems that were never released, so connected to S/3 and S/360 as well as
able to operate standalone).  The 3740 was quite a beast, with options for
printers.  I think all the diskettes had to be formatted by 3740 prior to
use in 3540, but this was early 70s technology (pretty much obsolete by
1980 as 3740 was very expensive, and didn't integrate well with any
mainframe.

On Thu, May 14, 2020 at 8:59 AM R.S.  wrote:

> I just checked bitsavers and found some information about 3540
> 1. Capacity - it depends. There were several types and subtypes, and
> sub-subtypes of diskettes. Approximately 256kB to 1,2 MB, however 3540
> used only those low capacity. (details available on request)
> 2. Feeding media - automatically, not manually.
> 3. There were two types of 3540, single and double drive.
> 4. The purpose was to deliver data from keypunch (wrong!) data entry
> stations. At the times before CRT screens became popular.
>
> However still I have no idea about system support. How to write data on
> diskette, how to read from diskette, how to recognize volume ID, etc.
> No, I'm not going to use it, but I'm just curious.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
> W dniu 13.05.2020 o 16:55, R.S. pisze:
> > Excuse me, what is IBM 3540?
> > This is mainframe forum so I checked all historical DASD, including
> > drum device and 2305 (which is not a drum) and found no such device. I
> > also reviewed disks for small systems (S3 System 32, System 34...
> > AS/400) and still no such device. Finally I found ~500MB SCSI attached
> > 3,5" disk with such number.
> > However I still don't know what is 3540. Any clue?
> >
> >
> > Update: I found it. It is diskette (yes, 8" floppy diskette drive).
> > Where can I find the reference about it? In new shining z/OS 2.4 JCL
> > Reference!
> >
> > Wow!
> >
> >
> > So, I dare to ask about this "still supported" device:
> > Was it Bus & Tag attached?
> > What parameters has the diskette? capacity, cylinders #, track length...
> > How it was recognized by operating system? Was it another DASD volume?
> > Every diskette was separate volume as tape cart?
> >
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> http://secure-web.cisco.com/1wVrLBOPCfZcSbq24vQSgWiQgcajqnDZUvk1VkRJQXZWjbXFMJM2QxzYWC92JTU3hxUYugZZzsCsBIXoyEsv5wKVP0-xZ9j6G9uTdCK8nurVDu5GglBOnZW0sc3wWZKC-hFfK1z7y8Lde5F8RBupbc517Udi-ZBCSfXpf_vMG0job3BcUACLdD0Kt23I7v-a0nR_eGgiBiE0thxTzdHX7zGwFTItYVle71YdPpYDbqF840VZwGVG3xIMhWyG7xXqOUChf2NylDnh-tC-cni_8vk_tIhpQ56kEDy_eZr3F3eDToPVL_0z9pwFX1nx2Hlb7Xb2cSre7VK7UPX_tiwo4vsJTqLEsT-ox8g_lwrYY6kOKlxJ-F4PqPavRItgQhmQ_HUHPs_xZq6otDnCl9ShM68ix07w_uwMbzov9SzCdDHMCjs9ovaLs1Ra5lMAeXHpS/http%3A%2F%2Fwww.mBank.pl,
>  e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> 

Re: What crashing COBOL systems reveal about applications maintenance -- GCN

2020-05-13 Thread Steve Thompson

I have z14 on the brain. I meant z12s.

On 5/13/20 9:10 PM, Clark Morris wrote:

[Default] On 13 May 2020 16:56:58 -0700, in bit.listserv.ibm-main
ste...@copper.net (Steve Thompson) wrote:


Suppose that they took a group of programmers and got the production online 
programs to all compile with COBOL 6.2 and OPT(1). Would they see a significant 
reduction in MSUs?  Assuming they are running on z14s minimally?


Is it likely in most environments that both the primary and fallback
computers (disaster recovery) are z14 or more recent?

Clark Morris


And from that, would they actually be able to do more transactions per hour?

Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct 
mistaks



On May 13, 2020, at 7:45 PM, Seymour J Metz  wrote:

?Conspicuously missing from the coverage is any evidence of delays or outages 
attributable to COBOL code running on mainframes. So far the stories I've seen 
turn out to relate to web servers or manual processing, not to the back end. 
Yeah, there could be issues with, e.g., CICS transactions written in COBOL, but 
none of the stories provide any reason to believe that to be the case.

More disturbing is the assumption that if they train hordes of COBOL 
programmers and bring all of the applications written in COBOL up to date, 
their troubles will be over. The elephant in the room is all of the code in 
other languages that has also been allowed to languish. It *all* needs to be 
documented and brought up to snuff.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mark Regan [marktre...@gmail.com]
Sent: Wednesday, May 13, 2020 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What crashing COBOL systems reveal about applications maintenance -- 
GCN

https://secure-web.cisco.com/1Ck2hssvPisqB8qyqrPsKlWMSh6SVj36qT95iEGNsvW41QGGjEH5TGYkmfjBEBCwAqsZp1UH2qlJxAPV-nlun5Dg56JO8lyf2QqkfAQDmic0ch6e5uj8J9A-Q3B3We8shuckCRr_XeQmGMDhXgd8TQyRlLdXH9bKy-iCiUCWHj2Kqen8MgwZNhQmpmPDXCZynS12e9_NREBCyJ-ImKut7vZYA4mccK38-ps5r3DJciC05kNl8kmdPhUg60gd1zZz7JURnW9weaJQKKDRSp57OBFh-n49E04rQSKCcaRjfOb7cGMU1n6iqgjTNOpmxmuPIjDr4aGw9aUMm9k3V6bRy75OJLSewcdQoYLb3wcGP1Iff-nYxUbFk8wp8l3lc_AhRdjTQ-059TNEsAQTLJUnMUEkSHuyT9PtOAgQrQdm_g-sdoO8Y415VmGflAy_9xBgfqdVJiOoYQb3UbkX7P6tc_A/https%3A%2F%2Fgcn.com%2Farticles%2F2020%2F05%2F12%2Fkeeping-mainframes-up-to-date.aspx%3Fm%3D1

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



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


Re: What crashing COBOL systems reveal about applications maintenance -- GCN

2020-05-13 Thread Clark Morris
[Default] On 13 May 2020 16:56:58 -0700, in bit.listserv.ibm-main
ste...@copper.net (Steve Thompson) wrote:

>Suppose that they took a group of programmers and got the production online 
>programs to all compile with COBOL 6.2 and OPT(1). Would they see a 
>significant reduction in MSUs?  Assuming they are running on z14s minimally?

Is it likely in most environments that both the primary and fallback
computers (disaster recovery) are z14 or more recent?

Clark Morris
>
>And from that, would they actually be able to do more transactions per hour?
>
>Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct 
>mistaks 
>
>
>> On May 13, 2020, at 7:45 PM, Seymour J Metz  wrote:
>> 
>> ?Conspicuously missing from the coverage is any evidence of delays or 
>> outages attributable to COBOL code running on mainframes. So far the stories 
>> I've seen turn out to relate to web servers or manual processing, not to the 
>> back end. Yeah, there could be issues with, e.g., CICS transactions written 
>> in COBOL, but none of the stories provide any reason to believe that to be 
>> the case.
>> 
>> More disturbing is the assumption that if they train hordes of COBOL 
>> programmers and bring all of the applications written in COBOL up to date, 
>> their troubles will be over. The elephant in the room is all of the code in 
>> other languages that has also been allowed to languish. It *all* needs to be 
>> documented and brought up to snuff.
>> 
>> 
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> 
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> Mark Regan [marktre...@gmail.com]
>> Sent: Wednesday, May 13, 2020 12:21 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: What crashing COBOL systems reveal about applications maintenance 
>> -- GCN
>> 
>> https://secure-web.cisco.com/1Ck2hssvPisqB8qyqrPsKlWMSh6SVj36qT95iEGNsvW41QGGjEH5TGYkmfjBEBCwAqsZp1UH2qlJxAPV-nlun5Dg56JO8lyf2QqkfAQDmic0ch6e5uj8J9A-Q3B3We8shuckCRr_XeQmGMDhXgd8TQyRlLdXH9bKy-iCiUCWHj2Kqen8MgwZNhQmpmPDXCZynS12e9_NREBCyJ-ImKut7vZYA4mccK38-ps5r3DJciC05kNl8kmdPhUg60gd1zZz7JURnW9weaJQKKDRSp57OBFh-n49E04rQSKCcaRjfOb7cGMU1n6iqgjTNOpmxmuPIjDr4aGw9aUMm9k3V6bRy75OJLSewcdQoYLb3wcGP1Iff-nYxUbFk8wp8l3lc_AhRdjTQ-059TNEsAQTLJUnMUEkSHuyT9PtOAgQrQdm_g-sdoO8Y415VmGflAy_9xBgfqdVJiOoYQb3UbkX7P6tc_A/https%3A%2F%2Fgcn.com%2Farticles%2F2020%2F05%2F12%2Fkeeping-mainframes-up-to-date.aspx%3Fm%3D1
>> 
>> --
>> 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: An older device query - still using??

2020-05-13 Thread Attila Fogarasi
The 3540 was the diskette part of the 3740 data entry workstation
(developed by GSD to replace keypunch and able to connect to all the FS
systems that were never released, so connected to S/3 and S/360 as well as
able to operate standalone).  The 3740 was quite a beast, with options for
printers.  I think all the diskettes had to be formatted by 3740 prior to
use in 3540, but this was early 70s technology (pretty much obsolete by
1980 as 3740 was very expensive, and didn't integrate well with any
mainframe.

On Thu, May 14, 2020 at 8:59 AM R.S.  wrote:

> I just checked bitsavers and found some information about 3540
> 1. Capacity - it depends. There were several types and subtypes, and
> sub-subtypes of diskettes. Approximately 256kB to 1,2 MB, however 3540
> used only those low capacity. (details available on request)
> 2. Feeding media - automatically, not manually.
> 3. There were two types of 3540, single and double drive.
> 4. The purpose was to deliver data from keypunch (wrong!) data entry
> stations. At the times before CRT screens became popular.
>
> However still I have no idea about system support. How to write data on
> diskette, how to read from diskette, how to recognize volume ID, etc.
> No, I'm not going to use it, but I'm just curious.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
> W dniu 13.05.2020 o 16:55, R.S. pisze:
> > Excuse me, what is IBM 3540?
> > This is mainframe forum so I checked all historical DASD, including
> > drum device and 2305 (which is not a drum) and found no such device. I
> > also reviewed disks for small systems (S3 System 32, System 34...
> > AS/400) and still no such device. Finally I found ~500MB SCSI attached
> > 3,5" disk with such number.
> > However I still don't know what is 3540. Any clue?
> >
> >
> > Update: I found it. It is diskette (yes, 8" floppy diskette drive).
> > Where can I find the reference about it? In new shining z/OS 2.4 JCL
> > Reference!
> >
> > Wow!
> >
> >
> > So, I dare to ask about this "still supported" device:
> > Was it Bus & Tag attached?
> > What parameters has the diskette? capacity, cylinders #, track length...
> > How it was recognized by operating system? Was it another DASD volume?
> > Every diskette was separate volume as tape cart?
> >
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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: An older device query - still using??

2020-05-13 Thread Seymour J Metz
Well, I have shelves of IBM logic manuals; my PL/I, Resident Library and 
Transient Library manuals have been waiting for years to be scanned. I could 
ask David to forward those to you, and ship a shelf at a time of the ones that 
I still have, shipping a new shelf every time I get the scans of the previous 
shelf. The oldest manuals that I have are from the 1960s, for 7070 Autocoder 
and such.

I've got hardware manuals for
Bendix
Burroughs
CDC
DEC
GE
Honeywell
IBM
RCA
SDS
UNIVAC

I've got manuals on various compatibility features and emulator programs.

Does the Airlines Buffer qualify as oddball?

There's really nothing that I want to keep on dead trees as long as I retain 
access to the information and can cite the manuals in Wikipedia articles.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
William Donzelli [wdonze...@gmail.com]
Sent: Wednesday, May 13, 2020 8:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

High priority topics would be things like oddball hardware, docs
dealing with RPQ features, maintenance docs, PCM and 3rd party
software and hardware.

Medium priority is marketing fluff, announcements, and not so technical stuff.

Low priority topics would by OS and language information, except for
oddball things (like 8100 and pre S/360).

And generally, older is better.

Honestly, if you would want to donate the whole pile (with the same
condition that it all gets archived, of course), no catalog of the
items would really need to be done. Some of us work on the shotgun
mentality - take it all, and expect a few good hits. When I go and
fetch document caches for Wild Hare (the Data General archive), I can
bring them 400 pounds of mixed DG paper, and if they can extract just
one or two things not already in the DG archive - success! Any extras
often get donated to other interested collectors.

--
Will

On Wed, May 13, 2020 at 8:18 PM Seymour J Metz  wrote:
>
> I've got, e.g., OS/360, SVS, MVS, hardware, manuals with 3 shelves of other 
> vendors, all uncataloged. If I'm going to have to catalog them then I'd like 
> to start with the ones likely to have the highest priority. Any guidance as 
> to what is most likely to be of interest?,
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> William Donzelli [wdonze...@gmail.com]
> Sent: Wednesday, May 13, 2020 8:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: An older device query - still using??
>
> Yes, a gigantic backlog, and the current situation has everything at a
> standstill. Al literally can not get to his scanner, as the museum is
> locked up.
>
> There are a few other archivists that provide acceptable high quality
> scans to bitsavers specs - maybe I will see if one of them can deal
> with your manuals.
>
> --
> Will
>
> On Wed, May 13, 2020 at 7:56 PM Seymour J Metz  wrote:
> >
> > Doesn't bitsavers have a huge backlog? I'm still waiting for manuals I gave 
> > several years ago to show up on their site. In particular I'm still waiting 
> > for the scans of the PL/I logic manuals so that I can annotate 
> > http://mason.gmu.edu/~smetz3/source/STOWBLDL.ASM with register equates.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> > William Donzelli [wdonze...@gmail.com]
> > Sent: Wednesday, May 13, 2020 12:19 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: An older device query - still using??
> >
> > Bitsavers are the ones to do the scans, but currently all of the
> > scanning equipment is locked up in the closed museum (and driving Al
> > nuts). I can see if any of the other archivists could tackle the job.
> >
> > But yes, you have goodies that would fill in some holes.
> >
> > --
> > Will
> >
> > On Wed, May 13, 2020 at 12:14 PM Seymour J Metz  wrote:
> > >
> > > If you're willing to pay the shipping, scan and OCR within a few months, 
> > > I've got hundreds of manuals, mostly IBM, that I'd be willing to give up 
> > > in exchange for sending me and bitsavers the PDF files.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf 
> > > of William Donzelli [wdonze...@gmail.com]
> > > Sent: Wednesday, May 13, 2020 11:50 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: An older device query - still using??
> > >
> > > Hey, that's my video. Go watch it!
> > >
> > > And remember, folks, I am always looking for this old stuff for the
> > > collection - mostly 

Re: An older device query - still using??

2020-05-13 Thread William Donzelli
High priority topics would be things like oddball hardware, docs
dealing with RPQ features, maintenance docs, PCM and 3rd party
software and hardware.

Medium priority is marketing fluff, announcements, and not so technical stuff.

Low priority topics would by OS and language information, except for
oddball things (like 8100 and pre S/360).

And generally, older is better.

Honestly, if you would want to donate the whole pile (with the same
condition that it all gets archived, of course), no catalog of the
items would really need to be done. Some of us work on the shotgun
mentality - take it all, and expect a few good hits. When I go and
fetch document caches for Wild Hare (the Data General archive), I can
bring them 400 pounds of mixed DG paper, and if they can extract just
one or two things not already in the DG archive - success! Any extras
often get donated to other interested collectors.

--
Will

On Wed, May 13, 2020 at 8:18 PM Seymour J Metz  wrote:
>
> I've got, e.g., OS/360, SVS, MVS, hardware, manuals with 3 shelves of other 
> vendors, all uncataloged. If I'm going to have to catalog them then I'd like 
> to start with the ones likely to have the highest priority. Any guidance as 
> to what is most likely to be of interest?,
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> William Donzelli [wdonze...@gmail.com]
> Sent: Wednesday, May 13, 2020 8:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: An older device query - still using??
>
> Yes, a gigantic backlog, and the current situation has everything at a
> standstill. Al literally can not get to his scanner, as the museum is
> locked up.
>
> There are a few other archivists that provide acceptable high quality
> scans to bitsavers specs - maybe I will see if one of them can deal
> with your manuals.
>
> --
> Will
>
> On Wed, May 13, 2020 at 7:56 PM Seymour J Metz  wrote:
> >
> > Doesn't bitsavers have a huge backlog? I'm still waiting for manuals I gave 
> > several years ago to show up on their site. In particular I'm still waiting 
> > for the scans of the PL/I logic manuals so that I can annotate 
> > http://mason.gmu.edu/~smetz3/source/STOWBLDL.ASM with register equates.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> > William Donzelli [wdonze...@gmail.com]
> > Sent: Wednesday, May 13, 2020 12:19 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: An older device query - still using??
> >
> > Bitsavers are the ones to do the scans, but currently all of the
> > scanning equipment is locked up in the closed museum (and driving Al
> > nuts). I can see if any of the other archivists could tackle the job.
> >
> > But yes, you have goodies that would fill in some holes.
> >
> > --
> > Will
> >
> > On Wed, May 13, 2020 at 12:14 PM Seymour J Metz  wrote:
> > >
> > > If you're willing to pay the shipping, scan and OCR within a few months, 
> > > I've got hundreds of manuals, mostly IBM, that I'd be willing to give up 
> > > in exchange for sending me and bitsavers the PDF files.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf 
> > > of William Donzelli [wdonze...@gmail.com]
> > > Sent: Wednesday, May 13, 2020 11:50 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: An older device query - still using??
> > >
> > > Hey, that's my video. Go watch it!
> > >
> > > And remember, folks, I am always looking for this old stuff for the
> > > collection - mostly anything pre-Z (I set up that limit so I do not
> > > overcollect).
> > >
> > > Anything from a box of IBM indicator lights (thanks, recent donor!) to
> > > a 3090. I would make that happen.
> > >
> > > --
> > > Will
> > >
> > > On Wed, May 13, 2020 at 11:23 AM Parwez Hamid  
> > > wrote:
> > > >
> > > > The 3540 was a BUS & TAG attached device. I am not saying that its 
> > > > still in use by anyone. However, a while ago, during my travels I did 
> > > > find customers were using strange BUS and TAG devices with channel 
> > > > convertors etc.
> > > >
> > > > 

Re: An older device query - still using??

2020-05-13 Thread Seymour J Metz
I've got, e.g., OS/360, SVS, MVS, hardware, manuals with 3 shelves of other 
vendors, all uncataloged. If I'm going to have to catalog them then I'd like to 
start with the ones likely to have the highest priority. Any guidance as to 
what is most likely to be of interest?,


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
William Donzelli [wdonze...@gmail.com]
Sent: Wednesday, May 13, 2020 8:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

Yes, a gigantic backlog, and the current situation has everything at a
standstill. Al literally can not get to his scanner, as the museum is
locked up.

There are a few other archivists that provide acceptable high quality
scans to bitsavers specs - maybe I will see if one of them can deal
with your manuals.

--
Will

On Wed, May 13, 2020 at 7:56 PM Seymour J Metz  wrote:
>
> Doesn't bitsavers have a huge backlog? I'm still waiting for manuals I gave 
> several years ago to show up on their site. In particular I'm still waiting 
> for the scans of the PL/I logic manuals so that I can annotate 
> http://mason.gmu.edu/~smetz3/source/STOWBLDL.ASM with register equates.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> William Donzelli [wdonze...@gmail.com]
> Sent: Wednesday, May 13, 2020 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: An older device query - still using??
>
> Bitsavers are the ones to do the scans, but currently all of the
> scanning equipment is locked up in the closed museum (and driving Al
> nuts). I can see if any of the other archivists could tackle the job.
>
> But yes, you have goodies that would fill in some holes.
>
> --
> Will
>
> On Wed, May 13, 2020 at 12:14 PM Seymour J Metz  wrote:
> >
> > If you're willing to pay the shipping, scan and OCR within a few months, 
> > I've got hundreds of manuals, mostly IBM, that I'd be willing to give up in 
> > exchange for sending me and bitsavers the PDF files.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> > William Donzelli [wdonze...@gmail.com]
> > Sent: Wednesday, May 13, 2020 11:50 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: An older device query - still using??
> >
> > Hey, that's my video. Go watch it!
> >
> > And remember, folks, I am always looking for this old stuff for the
> > collection - mostly anything pre-Z (I set up that limit so I do not
> > overcollect).
> >
> > Anything from a box of IBM indicator lights (thanks, recent donor!) to
> > a 3090. I would make that happen.
> >
> > --
> > Will
> >
> > On Wed, May 13, 2020 at 11:23 AM Parwez Hamid  
> > wrote:
> > >
> > > The 3540 was a BUS & TAG attached device. I am not saying that its still 
> > > in use by anyone. However, a while ago, during my travels I did find 
> > > customers were using strange BUS and TAG devices with channel convertors 
> > > etc.
> > >
> > > https://secure-web.cisco.com/1mtE7GVJOAzGIYFuFqh6r2mVx4dlsdCqJFKLtP-BE_NRdp0o136SQ2kteePdaAMkANW-1G_2I4UffM2S9YHQMDxloccnWCMSJQHvaJe15bcuNgUP5XDJ4moMCvAJ4gpm8pZddq2owyou4spOB_FpUyRt2ZUjTaKiPDMBKaaBVm_B2HNGsdHdLZudtpJ4VcPcIJlDz_WKGwsznjlABIaJzhgIoIErnLu5GNBaocG0OPuZGZ1d_v1EYySmZLgdh9RQiCTB6qOiEh0O8gEVCglLupFS9mgzbMmrPto-o9OzDyS4rquX-ewDNPSGcGSCnOLvcUgRo3OLShxJckXvh06fhl1-FQXZ5Mw61Dm-WqJEnNfYEVcgcOCvO3DkBEbxc_fqIaLJ1oy0hkj5daaSHYDb6c1aF8AsOKvVAUYy4YyHe19uAt_FyUTZbLRsWlGYfjjmZXCVSHZGalHH2AGXtFx4PGA/https%3A%2F%2Fwww.reddit.com%2Fr%2Fretrobattlestations%2Fcomments%2F627vtu%2Fbig_disk_week_ibm_3540_s370_channel_attached_8%2F
> > > 

Re: s0c4 accessing RAX control Block

2020-05-13 Thread Binyamin Dissen
As always, show your code and what the system reported as the abend details.

On Wed, 13 May 2020 19:02:34 -0400 Joseph Reichman 
wrote:

:>Hi 
:>
:> 
:>
:>I am trying to get info on virtual storage towards that end  I got a s0c4
:>pic 10 accessing a field in the RAX control block I got the address from the
:>ASCB->ASCBRSME the doc says its in SQA not fetch protected
:>
:>I later did  VSMSQA,AREA(RAXID,800),LINKAGE=SYSTEM and got a RC 4
:>
:> 
:>
:>The ASCBRSME seems to have a valid pointer   

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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


Re: An older device query - still using??

2020-05-13 Thread William Donzelli
Yes, a gigantic backlog, and the current situation has everything at a
standstill. Al literally can not get to his scanner, as the museum is
locked up.

There are a few other archivists that provide acceptable high quality
scans to bitsavers specs - maybe I will see if one of them can deal
with your manuals.

--
Will

On Wed, May 13, 2020 at 7:56 PM Seymour J Metz  wrote:
>
> Doesn't bitsavers have a huge backlog? I'm still waiting for manuals I gave 
> several years ago to show up on their site. In particular I'm still waiting 
> for the scans of the PL/I logic manuals so that I can annotate 
> http://mason.gmu.edu/~smetz3/source/STOWBLDL.ASM with register equates.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> William Donzelli [wdonze...@gmail.com]
> Sent: Wednesday, May 13, 2020 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: An older device query - still using??
>
> Bitsavers are the ones to do the scans, but currently all of the
> scanning equipment is locked up in the closed museum (and driving Al
> nuts). I can see if any of the other archivists could tackle the job.
>
> But yes, you have goodies that would fill in some holes.
>
> --
> Will
>
> On Wed, May 13, 2020 at 12:14 PM Seymour J Metz  wrote:
> >
> > If you're willing to pay the shipping, scan and OCR within a few months, 
> > I've got hundreds of manuals, mostly IBM, that I'd be willing to give up in 
> > exchange for sending me and bitsavers the PDF files.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> > William Donzelli [wdonze...@gmail.com]
> > Sent: Wednesday, May 13, 2020 11:50 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: An older device query - still using??
> >
> > Hey, that's my video. Go watch it!
> >
> > And remember, folks, I am always looking for this old stuff for the
> > collection - mostly anything pre-Z (I set up that limit so I do not
> > overcollect).
> >
> > Anything from a box of IBM indicator lights (thanks, recent donor!) to
> > a 3090. I would make that happen.
> >
> > --
> > Will
> >
> > On Wed, May 13, 2020 at 11:23 AM Parwez Hamid  
> > wrote:
> > >
> > > The 3540 was a BUS & TAG attached device. I am not saying that its still 
> > > in use by anyone. However, a while ago, during my travels I did find 
> > > customers were using strange BUS and TAG devices with channel convertors 
> > > etc.
> > >
> > > https://secure-web.cisco.com/1mtE7GVJOAzGIYFuFqh6r2mVx4dlsdCqJFKLtP-BE_NRdp0o136SQ2kteePdaAMkANW-1G_2I4UffM2S9YHQMDxloccnWCMSJQHvaJe15bcuNgUP5XDJ4moMCvAJ4gpm8pZddq2owyou4spOB_FpUyRt2ZUjTaKiPDMBKaaBVm_B2HNGsdHdLZudtpJ4VcPcIJlDz_WKGwsznjlABIaJzhgIoIErnLu5GNBaocG0OPuZGZ1d_v1EYySmZLgdh9RQiCTB6qOiEh0O8gEVCglLupFS9mgzbMmrPto-o9OzDyS4rquX-ewDNPSGcGSCnOLvcUgRo3OLShxJckXvh06fhl1-FQXZ5Mw61Dm-WqJEnNfYEVcgcOCvO3DkBEbxc_fqIaLJ1oy0hkj5daaSHYDb6c1aF8AsOKvVAUYy4YyHe19uAt_FyUTZbLRsWlGYfjjmZXCVSHZGalHH2AGXtFx4PGA/https%3A%2F%2Fwww.reddit.com%2Fr%2Fretrobattlestations%2Fcomments%2F627vtu%2Fbig_disk_week_ibm_3540_s370_channel_attached_8%2F
> > > [https://secure-web.cisco.com/1r2YkZjH8aoOGoXpxhb3jByHB6ZR5GoHw4j7qlIzl95t5AjHavIFjUGtDi9A6nyMydIYRDag0kGYMLvtZG7SU_5ZAj0STR8MI3R6UMaaH7US2xmPA3cTUhmTkBoPG57eXeVYVM5YWK6_UA5Jc86zStgzUX_NyWuBMMnRop5MVHffxSgRGoBLzE5LBzG1mS2yfwJCd75rOszcRuRz9povyG_G4C77na9pJ40aORVAkVX8VDQL4ekFBBtCZxULnR4qECdTxuVUcq9tDrinXjyodnkr_qVrrHEE0QX7HyrPOWlKSgWB0O3WjPQ9dAgpTqp9Y5rFm12XgJi9wz0AtZBPBR8gqO-hMINyrz_qkjOZpPIP83kkY54bUMzwo19o9RPL_b3XnzYIFd7_kok781_7kuO50zoilAhpHwFMpSF7yQaT3vmh8j1KyCHv0R1QPMtxAVj9ILrd4vYxntkcfnjJG2w/https%3A%2F%2Fpreview.redd.it%2F1wgw7b1vndoy.jpg%3Fauto%3Dwebp%26s%3D700536458793462d84bccdfbea463e2ff9ccfc59%5D
> > > [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive : 
> > > 

Re: Oil futures and computer "help"

2020-05-13 Thread Seymour J Metz
The title is misleading; no computers were harmed in the shooting of this 
movie. It's the application that was busted.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Wednesday, May 13, 2020 7:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Oil futures and computer "help"

This fascinating article isn't really on the topic of mainframes, but we've 
been talking about similar things recently and I thought some would be 
interested:

https://www.bloomberg.com/news/articles/2020-05-08/oil-crash-busted-a-broker-s-computers-and-inflicted-huge-losses

The main player is a futures speculator who watched the price of oil futures 
drop fantastically low and bought like crazy - never realizing that the price 
~could~ go negative.  The brokerage house's trading application didn't know it 
either:  "Crude was actually around negative $3.70 a barrel when Shah’s screen 
had it at 1 centCompounding the problem, and a big reason why Shah lost an 
unbelievable amount in a few hours, is that the negative numbers also blew up 
the model Interactive Brokers used to calculate the amount of margin -- aka 
collateral -- that customers needed to secure their accounts."

"At midnight, Shah got the devastating news: he owed Interactive Brokers $9 
million. He’d started the day with $77,000 in his account."

Another player "bought contracts for his friends on Interactive Brokers that 
day at $11 and between $4 and $5. Just after 2 p.m. New York time, his trading 
screen froze. 'The price feed went black, there were no bids or offers 
anymore,' he said in an interview. Yet as far as he knew at this point, 
according to his Interactive Brokers account, he didn’t have anything to worry 
about as trading closed for the day."

"Besides locking up because of negative prices, a second issue concerned the 
amount of money Interactive Brokers required its customers to have on hand in 
order to trade. Known as margin, it’s a vital risk measure to ensure traders 
don’t lose more than they can afford. For the 212 oil contracts Shah bought for 
1 cent each, the broker only required his account to have $30 of margin per 
contract. It was as if Interactive Brokers thought the potential loss of buying 
at one cent was one cent, rather than the almost unlimited downside that 
negative prices imply, he said."

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The Constitution is supposed to define the powers of the federal government 
-- authorizing some powers, which are enumerated, while reserving all other 
powers to the states and the people. This means that the first question we 
should ask when a new law is proposed is: "Does the Constitution allow the 
federal government to do this?"  -Joseph Sobran, 2001-01-06 */

--
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: What crashing COBOL systems reveal about applications maintenance -- GCN

2020-05-13 Thread Steve Thompson
Suppose that they took a group of programmers and got the production online 
programs to all compile with COBOL 6.2 and OPT(1). Would they see a significant 
reduction in MSUs?  Assuming they are running on z14s minimally?

And from that, would they actually be able to do more transactions per hour?

Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct 
mistaks 


> On May 13, 2020, at 7:45 PM, Seymour J Metz  wrote:
> 
> Conspicuously missing from the coverage is any evidence of delays or outages 
> attributable to COBOL code running on mainframes. So far the stories I've 
> seen turn out to relate to web servers or manual processing, not to the back 
> end. Yeah, there could be issues with, e.g., CICS transactions written in 
> COBOL, but none of the stories provide any reason to believe that to be the 
> case.
> 
> More disturbing is the assumption that if they train hordes of COBOL 
> programmers and bring all of the applications written in COBOL up to date, 
> their troubles will be over. The elephant in the room is all of the code in 
> other languages that has also been allowed to languish. It *all* needs to be 
> documented and brought up to snuff.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Mark Regan [marktre...@gmail.com]
> Sent: Wednesday, May 13, 2020 12:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: What crashing COBOL systems reveal about applications maintenance -- 
> GCN
> 
> https://secure-web.cisco.com/1Ck2hssvPisqB8qyqrPsKlWMSh6SVj36qT95iEGNsvW41QGGjEH5TGYkmfjBEBCwAqsZp1UH2qlJxAPV-nlun5Dg56JO8lyf2QqkfAQDmic0ch6e5uj8J9A-Q3B3We8shuckCRr_XeQmGMDhXgd8TQyRlLdXH9bKy-iCiUCWHj2Kqen8MgwZNhQmpmPDXCZynS12e9_NREBCyJ-ImKut7vZYA4mccK38-ps5r3DJciC05kNl8kmdPhUg60gd1zZz7JURnW9weaJQKKDRSp57OBFh-n49E04rQSKCcaRjfOb7cGMU1n6iqgjTNOpmxmuPIjDr4aGw9aUMm9k3V6bRy75OJLSewcdQoYLb3wcGP1Iff-nYxUbFk8wp8l3lc_AhRdjTQ-059TNEsAQTLJUnMUEkSHuyT9PtOAgQrQdm_g-sdoO8Y415VmGflAy_9xBgfqdVJiOoYQb3UbkX7P6tc_A/https%3A%2F%2Fgcn.com%2Farticles%2F2020%2F05%2F12%2Fkeeping-mainframes-up-to-date.aspx%3Fm%3D1
> 
> --
> 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: An older device query - still using??

2020-05-13 Thread Seymour J Metz
Doesn't bitsavers have a huge backlog? I'm still waiting for manuals I gave 
several years ago to show up on their site. In particular I'm still waiting for 
the scans of the PL/I logic manuals so that I can annotate 
http://mason.gmu.edu/~smetz3/source/STOWBLDL.ASM with register equates.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
William Donzelli [wdonze...@gmail.com]
Sent: Wednesday, May 13, 2020 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

Bitsavers are the ones to do the scans, but currently all of the
scanning equipment is locked up in the closed museum (and driving Al
nuts). I can see if any of the other archivists could tackle the job.

But yes, you have goodies that would fill in some holes.

--
Will

On Wed, May 13, 2020 at 12:14 PM Seymour J Metz  wrote:
>
> If you're willing to pay the shipping, scan and OCR within a few months, I've 
> got hundreds of manuals, mostly IBM, that I'd be willing to give up in 
> exchange for sending me and bitsavers the PDF files.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> William Donzelli [wdonze...@gmail.com]
> Sent: Wednesday, May 13, 2020 11:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: An older device query - still using??
>
> Hey, that's my video. Go watch it!
>
> And remember, folks, I am always looking for this old stuff for the
> collection - mostly anything pre-Z (I set up that limit so I do not
> overcollect).
>
> Anything from a box of IBM indicator lights (thanks, recent donor!) to
> a 3090. I would make that happen.
>
> --
> Will
>
> On Wed, May 13, 2020 at 11:23 AM Parwez Hamid  
> wrote:
> >
> > The 3540 was a BUS & TAG attached device. I am not saying that its still in 
> > use by anyone. However, a while ago, during my travels I did find customers 
> > were using strange BUS and TAG devices with channel convertors etc.
> >
> > https://secure-web.cisco.com/1mtE7GVJOAzGIYFuFqh6r2mVx4dlsdCqJFKLtP-BE_NRdp0o136SQ2kteePdaAMkANW-1G_2I4UffM2S9YHQMDxloccnWCMSJQHvaJe15bcuNgUP5XDJ4moMCvAJ4gpm8pZddq2owyou4spOB_FpUyRt2ZUjTaKiPDMBKaaBVm_B2HNGsdHdLZudtpJ4VcPcIJlDz_WKGwsznjlABIaJzhgIoIErnLu5GNBaocG0OPuZGZ1d_v1EYySmZLgdh9RQiCTB6qOiEh0O8gEVCglLupFS9mgzbMmrPto-o9OzDyS4rquX-ewDNPSGcGSCnOLvcUgRo3OLShxJckXvh06fhl1-FQXZ5Mw61Dm-WqJEnNfYEVcgcOCvO3DkBEbxc_fqIaLJ1oy0hkj5daaSHYDb6c1aF8AsOKvVAUYy4YyHe19uAt_FyUTZbLRsWlGYfjjmZXCVSHZGalHH2AGXtFx4PGA/https%3A%2F%2Fwww.reddit.com%2Fr%2Fretrobattlestations%2Fcomments%2F627vtu%2Fbig_disk_week_ibm_3540_s370_channel_attached_8%2F
> > [https://secure-web.cisco.com/1r2YkZjH8aoOGoXpxhb3jByHB6ZR5GoHw4j7qlIzl95t5AjHavIFjUGtDi9A6nyMydIYRDag0kGYMLvtZG7SU_5ZAj0STR8MI3R6UMaaH7US2xmPA3cTUhmTkBoPG57eXeVYVM5YWK6_UA5Jc86zStgzUX_NyWuBMMnRop5MVHffxSgRGoBLzE5LBzG1mS2yfwJCd75rOszcRuRz9povyG_G4C77na9pJ40aORVAkVX8VDQL4ekFBBtCZxULnR4qECdTxuVUcq9tDrinXjyodnkr_qVrrHEE0QX7HyrPOWlKSgWB0O3WjPQ9dAgpTqp9Y5rFm12XgJi9wz0AtZBPBR8gqO-hMINyrz_qkjOZpPIP83kkY54bUMzwo19o9RPL_b3XnzYIFd7_kok781_7kuO50zoilAhpHwFMpSF7yQaT3vmh8j1KyCHv0R1QPMtxAVj9ILrd4vYxntkcfnjJG2w/https%3A%2F%2Fpreview.redd.it%2F1wgw7b1vndoy.jpg%3Fauto%3Dwebp%26s%3D700536458793462d84bccdfbea463e2ff9ccfc59%5D
> > [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive : 
> > retrobattlestations
> > [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive. Big Disk 
> > Week. Close. 30. Posted by. u/uniservo. 2 years ago. Archived [Big Disk 
> > Week] IBM 3540 S/370 channel attached 8" floppy drive. Big Disk Week. 10 
> > 

Re: What crashing COBOL systems reveal about applications maintenance -- GCN

2020-05-13 Thread Seymour J Metz
Conspicuously missing from the coverage is any evidence of delays or outages 
attributable to COBOL code running on mainframes. So far the stories I've seen 
turn out to relate to web servers or manual processing, not to the back end. 
Yeah, there could be issues with, e.g., CICS transactions written in COBOL, but 
none of the stories provide any reason to believe that to be the case.

More disturbing is the assumption that if they train hordes of COBOL 
programmers and bring all of the applications written in COBOL up to date, 
their troubles will be over. The elephant in the room is all of the code in 
other languages that has also been allowed to languish. It *all* needs to be 
documented and brought up to snuff.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mark Regan [marktre...@gmail.com]
Sent: Wednesday, May 13, 2020 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What crashing COBOL systems reveal about applications maintenance -- 
GCN

https://secure-web.cisco.com/1Ck2hssvPisqB8qyqrPsKlWMSh6SVj36qT95iEGNsvW41QGGjEH5TGYkmfjBEBCwAqsZp1UH2qlJxAPV-nlun5Dg56JO8lyf2QqkfAQDmic0ch6e5uj8J9A-Q3B3We8shuckCRr_XeQmGMDhXgd8TQyRlLdXH9bKy-iCiUCWHj2Kqen8MgwZNhQmpmPDXCZynS12e9_NREBCyJ-ImKut7vZYA4mccK38-ps5r3DJciC05kNl8kmdPhUg60gd1zZz7JURnW9weaJQKKDRSp57OBFh-n49E04rQSKCcaRjfOb7cGMU1n6iqgjTNOpmxmuPIjDr4aGw9aUMm9k3V6bRy75OJLSewcdQoYLb3wcGP1Iff-nYxUbFk8wp8l3lc_AhRdjTQ-059TNEsAQTLJUnMUEkSHuyT9PtOAgQrQdm_g-sdoO8Y415VmGflAy_9xBgfqdVJiOoYQb3UbkX7P6tc_A/https%3A%2F%2Fgcn.com%2Farticles%2F2020%2F05%2F12%2Fkeeping-mainframes-up-to-date.aspx%3Fm%3D1

--
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: Oil futures and computer "help"

2020-05-13 Thread Frank Swarbrick
Never trust a computer application that you yourself didn't write.  And even 
then don't trust it.

Only slightly kidding.


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Wednesday, May 13, 2020 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Oil futures and computer "help"

This fascinating article isn't really on the topic of mainframes, but we've 
been talking about similar things recently and I thought some would be 
interested:

https://www.bloomberg.com/news/articles/2020-05-08/oil-crash-busted-a-broker-s-computers-and-inflicted-huge-losses

The main player is a futures speculator who watched the price of oil futures 
drop fantastically low and bought like crazy - never realizing that the price 
~could~ go negative.  The brokerage house's trading application didn't know it 
either:  "Crude was actually around negative $3.70 a barrel when Shah’s screen 
had it at 1 centCompounding the problem, and a big reason why Shah lost an 
unbelievable amount in a few hours, is that the negative numbers also blew up 
the model Interactive Brokers used to calculate the amount of margin -- aka 
collateral -- that customers needed to secure their accounts."

"At midnight, Shah got the devastating news: he owed Interactive Brokers $9 
million. He’d started the day with $77,000 in his account."

Another player "bought contracts for his friends on Interactive Brokers that 
day at $11 and between $4 and $5. Just after 2 p.m. New York time, his trading 
screen froze. 'The price feed went black, there were no bids or offers 
anymore,' he said in an interview. Yet as far as he knew at this point, 
according to his Interactive Brokers account, he didn’t have anything to worry 
about as trading closed for the day."

"Besides locking up because of negative prices, a second issue concerned the 
amount of money Interactive Brokers required its customers to have on hand in 
order to trade. Known as margin, it’s a vital risk measure to ensure traders 
don’t lose more than they can afford. For the 212 oil contracts Shah bought for 
1 cent each, the broker only required his account to have $30 of margin per 
contract. It was as if Interactive Brokers thought the potential loss of buying 
at one cent was one cent, rather than the almost unlimited downside that 
negative prices imply, he said."

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The Constitution is supposed to define the powers of the federal government 
-- authorizing some powers, which are enumerated, while reserving all other 
powers to the states and the people. This means that the first question we 
should ask when a new law is proposed is: "Does the Constitution allow the 
federal government to do this?"  -Joseph Sobran, 2001-01-06 */

--
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: s0c4 accessing RAX control Block

2020-05-13 Thread Joseph Reichman
Thanks all my progs are AMODE 31 RMODE ANY don't know what happened here
thanks again
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Wednesday, May 13, 2020 7:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: s0c4 accessing RAX control Block

Are you in the correct addressing mode?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Joseph Reichman [reichman...@gmail.com]
Sent: Wednesday, May 13, 2020 7:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: s0c4 accessing RAX control Block

Hi



I am trying to get info on virtual storage towards that end  I got a s0c4
pic 10 accessing a field in the RAX control block I got the address from the
ASCB->ASCBRSME the doc says its in SQA not fetch protected

I later did  VSMSQA,AREA(RAXID,800),LINKAGE=SYSTEM and got a RC 4



The ASCBRSME seems to have a valid pointer






--
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: s0c4 accessing RAX control Block

2020-05-13 Thread Attila Fogarasi
Check that ASCBRSMA is not zero.  There used to be a window when
ASCBRSME is set (has an address) but ASCBRSMA is still zero and using
ASCBRSME causes S0C4 until ASCBRSMA is set (after some initialization is
completed).  Ran into this many years ago, maybe you have some variant of
this rather counter-intuitive problem (no RAB yet though the extension RAX
has an address, presumably residual).

On Thu, May 14, 2020 at 9:02 AM Joseph Reichman 
wrote:

> Hi
>
>
>
> I am trying to get info on virtual storage towards that end  I got a s0c4
> pic 10 accessing a field in the RAX control block I got the address from
> the
> ASCB->ASCBRSME the doc says its in SQA not fetch protected
>
> I later did  VSMSQA,AREA(RAXID,800),LINKAGE=SYSTEM and got a RC 4
>
>
>
> The ASCBRSME seems to have a valid pointer
>
>
>
>
>
>
> --
> 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


Oil futures and computer "help"

2020-05-13 Thread Bob Bridges
This fascinating article isn't really on the topic of mainframes, but we've 
been talking about similar things recently and I thought some would be 
interested:

https://www.bloomberg.com/news/articles/2020-05-08/oil-crash-busted-a-broker-s-computers-and-inflicted-huge-losses

The main player is a futures speculator who watched the price of oil futures 
drop fantastically low and bought like crazy - never realizing that the price 
~could~ go negative.  The brokerage house's trading application didn't know it 
either:  "Crude was actually around negative $3.70 a barrel when Shah’s screen 
had it at 1 centCompounding the problem, and a big reason why Shah lost an 
unbelievable amount in a few hours, is that the negative numbers also blew up 
the model Interactive Brokers used to calculate the amount of margin -- aka 
collateral -- that customers needed to secure their accounts."

"At midnight, Shah got the devastating news: he owed Interactive Brokers $9 
million. He’d started the day with $77,000 in his account."

Another player "bought contracts for his friends on Interactive Brokers that 
day at $11 and between $4 and $5. Just after 2 p.m. New York time, his trading 
screen froze. 'The price feed went black, there were no bids or offers 
anymore,' he said in an interview. Yet as far as he knew at this point, 
according to his Interactive Brokers account, he didn’t have anything to worry 
about as trading closed for the day."

"Besides locking up because of negative prices, a second issue concerned the 
amount of money Interactive Brokers required its customers to have on hand in 
order to trade. Known as margin, it’s a vital risk measure to ensure traders 
don’t lose more than they can afford. For the 212 oil contracts Shah bought for 
1 cent each, the broker only required his account to have $30 of margin per 
contract. It was as if Interactive Brokers thought the potential loss of buying 
at one cent was one cent, rather than the almost unlimited downside that 
negative prices imply, he said."

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The Constitution is supposed to define the powers of the federal government 
-- authorizing some powers, which are enumerated, while reserving all other 
powers to the states and the people. This means that the first question we 
should ask when a new law is proposed is: "Does the Constitution allow the 
federal government to do this?"  -Joseph Sobran, 2001-01-06 */

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


Re: s0c4 accessing RAX control Block

2020-05-13 Thread Seymour J Metz
Are you in the correct addressing mode?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joseph Reichman [reichman...@gmail.com]
Sent: Wednesday, May 13, 2020 7:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: s0c4 accessing RAX control Block

Hi



I am trying to get info on virtual storage towards that end  I got a s0c4
pic 10 accessing a field in the RAX control block I got the address from the
ASCB->ASCBRSME the doc says its in SQA not fetch protected

I later did  VSMSQA,AREA(RAXID,800),LINKAGE=SYSTEM and got a RC 4



The ASCBRSME seems to have a valid pointer






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


s0c4 accessing RAX control Block

2020-05-13 Thread Joseph Reichman
Hi 

 

I am trying to get info on virtual storage towards that end  I got a s0c4
pic 10 accessing a field in the RAX control block I got the address from the
ASCB->ASCBRSME the doc says its in SQA not fetch protected

I later did  VSMSQA,AREA(RAXID,800),LINKAGE=SYSTEM and got a RC 4

 

The ASCBRSME seems to have a valid pointer   

 

 


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


Re: An older device query - still using??

2020-05-13 Thread R.S.

I just checked bitsavers and found some information about 3540
1. Capacity - it depends. There were several types and subtypes, and 
sub-subtypes of diskettes. Approximately 256kB to 1,2 MB, however 3540 
used only those low capacity. (details available on request)

2. Feeding media - automatically, not manually.
3. There were two types of 3540, single and double drive.
4. The purpose was to deliver data from keypunch (wrong!) data entry 
stations. At the times before CRT screens became popular.


However still I have no idea about system support. How to write data on 
diskette, how to read from diskette, how to recognize volume ID, etc.

No, I'm not going to use it, but I'm just curious.

--
Radoslaw Skorupka
Lodz, Poland







W dniu 13.05.2020 o 16:55, R.S. pisze:

Excuse me, what is IBM 3540?
This is mainframe forum so I checked all historical DASD, including 
drum device and 2305 (which is not a drum) and found no such device. I 
also reviewed disks for small systems (S3 System 32, System 34... 
AS/400) and still no such device. Finally I found ~500MB SCSI attached 
3,5" disk with such number.

However I still don't know what is 3540. Any clue?


Update: I found it. It is diskette (yes, 8" floppy diskette drive).
Where can I find the reference about it? In new shining z/OS 2.4 JCL 
Reference!


Wow!


So, I dare to ask about this "still supported" device:
Was it Bus & Tag attached?
What parameters has the diskette? capacity, cylinders #, track length...
How it was recognized by operating system? Was it another DASD volume?
Every diskette was separate volume as tape cart?





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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


Re: An older device query - still using??

2020-05-13 Thread Mike Schwab
Well, how about posting a list of the document numbers and name.  Then
people can tell you which ones have been scanned and can be discarded.
Then people who want a particular manual enough to scan it will
volunteer for THAT manual.  That would leave you with the unscanned
manuals of lower priority.

On Wed, May 13, 2020 at 4:14 PM Seymour J Metz  wrote:
>
> If you're willing to pay the shipping, scan and OCR within a few months, I've 
> got hundreds of manuals, mostly IBM, that I'd be willing to give up in 
> exchange for sending me and bitsavers the PDF files.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> William Donzelli [wdonze...@gmail.com]
> Sent: Wednesday, May 13, 2020 11:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: An older device query - still using??
>
> Hey, that's my video. Go watch it!
>
> And remember, folks, I am always looking for this old stuff for the
> collection - mostly anything pre-Z (I set up that limit so I do not
> overcollect).
>
> Anything from a box of IBM indicator lights (thanks, recent donor!) to
> a 3090. I would make that happen.
>
> --
> Will
>
> On Wed, May 13, 2020 at 11:23 AM Parwez Hamid  
> wrote:
> >
> > The 3540 was a BUS & TAG attached device. I am not saying that its still in 
> > use by anyone. However, a while ago, during my travels I did find customers 
> > were using strange BUS and TAG devices with channel convertors etc.
> >
> > https://secure-web.cisco.com/1mtE7GVJOAzGIYFuFqh6r2mVx4dlsdCqJFKLtP-BE_NRdp0o136SQ2kteePdaAMkANW-1G_2I4UffM2S9YHQMDxloccnWCMSJQHvaJe15bcuNgUP5XDJ4moMCvAJ4gpm8pZddq2owyou4spOB_FpUyRt2ZUjTaKiPDMBKaaBVm_B2HNGsdHdLZudtpJ4VcPcIJlDz_WKGwsznjlABIaJzhgIoIErnLu5GNBaocG0OPuZGZ1d_v1EYySmZLgdh9RQiCTB6qOiEh0O8gEVCglLupFS9mgzbMmrPto-o9OzDyS4rquX-ewDNPSGcGSCnOLvcUgRo3OLShxJckXvh06fhl1-FQXZ5Mw61Dm-WqJEnNfYEVcgcOCvO3DkBEbxc_fqIaLJ1oy0hkj5daaSHYDb6c1aF8AsOKvVAUYy4YyHe19uAt_FyUTZbLRsWlGYfjjmZXCVSHZGalHH2AGXtFx4PGA/https%3A%2F%2Fwww.reddit.com%2Fr%2Fretrobattlestations%2Fcomments%2F627vtu%2Fbig_disk_week_ibm_3540_s370_channel_attached_8%2F
> > [https://secure-web.cisco.com/1r2YkZjH8aoOGoXpxhb3jByHB6ZR5GoHw4j7qlIzl95t5AjHavIFjUGtDi9A6nyMydIYRDag0kGYMLvtZG7SU_5ZAj0STR8MI3R6UMaaH7US2xmPA3cTUhmTkBoPG57eXeVYVM5YWK6_UA5Jc86zStgzUX_NyWuBMMnRop5MVHffxSgRGoBLzE5LBzG1mS2yfwJCd75rOszcRuRz9povyG_G4C77na9pJ40aORVAkVX8VDQL4ekFBBtCZxULnR4qECdTxuVUcq9tDrinXjyodnkr_qVrrHEE0QX7HyrPOWlKSgWB0O3WjPQ9dAgpTqp9Y5rFm12XgJi9wz0AtZBPBR8gqO-hMINyrz_qkjOZpPIP83kkY54bUMzwo19o9RPL_b3XnzYIFd7_kok781_7kuO50zoilAhpHwFMpSF7yQaT3vmh8j1KyCHv0R1QPMtxAVj9ILrd4vYxntkcfnjJG2w/https%3A%2F%2Fpreview.redd.it%2F1wgw7b1vndoy.jpg%3Fauto%3Dwebp%26s%3D700536458793462d84bccdfbea463e2ff9ccfc59%5D
> > [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive : 
> > retrobattlestations
> > [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive. Big Disk 
> > Week. Close. 30. Posted by. u/uniservo. 2 years ago. Archived [Big Disk 
> > Week] IBM 3540 S/370 channel attached 8" floppy drive. Big Disk Week. 10 
> > comments. share. save hide report. 98% Upvoted. This thread is archived. 
> > New comments cannot be posted and votes cannot be cast ...
> > 

Re: An older device query - still using??

2020-05-13 Thread Carmen Vitullo
ah 4341, Boeing Philly used one to perform a proof of concept for an electronic 
mock up system for V-22 design, it was a standalone system, 2 tape drives, no 
network adapters that I recall. 
@ Sears before that the 4331 ? first self diagnosing processor, a red error 
code on the systems master console, below the PSW display showed the error 
code, call IBM, tell them the code and they came it with the parts ! 



Carmen Vitullo 

- Original Message -

From: "Dana Mitchell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 13, 2020 12:07:29 PM 
Subject: Re: An older device query - still using?? 

On Wed, 13 May 2020 11:35:00 -0400, Tony Thigpen  wrote: 

>The 4331 had an internal diskette drive (accessed from the top of the 
>cpu) that emulated a 3540. It was the same drive as used for IML. We 
>also had one attached to our System-3/15D. 
> 
>Tony Thigpen 

I remember it well, the conversion from 4331 to 4341 was a particularly painful 
conversion due to all the built-in adapters and such that 4331 possesed that 
the 4341 required channel attached control units. In order to swap to the new 
CPU, we had to install 3540, 3274, 3880, 3705 (along with NCP, EP, and SSP) and 
new tape drives. 
Dana 

-- 
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: An older device query - still using??

2020-05-13 Thread Dana Mitchell
On Wed, 13 May 2020 11:35:00 -0400, Tony Thigpen  wrote:

>The 4331 had an internal diskette drive (accessed from the top of the
>cpu) that emulated a 3540. It was the same drive as used for IML. We
>also had one attached to our System-3/15D.
>
>Tony Thigpen

I remember it well,  the conversion from 4331 to 4341 was a particularly 
painful conversion due to all the built-in adapters and such that 4331 possesed 
that the 4341 required channel attached control units.   In order to swap to 
the new CPU,  we had to install 3540,  3274, 3880, 3705 (along with NCP, EP, 
and SSP) and new tape drives.
Dana

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


Re: An older device query - still using??

2020-05-13 Thread Tony Thigpen

manual feed.

Tony Thigpen

Seymour J Metz wrote on 5/13/20 12:17 PM:

How do you emulate an input hopper? The 3540 wasn't a simple 8" floppy drive; 
it had a feeder so you could read a string of diskettes with no manual intervention 
between them.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Wednesday, May 13, 2020 11:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

The 4331 had an internal diskette drive (accessed from the top of the
cpu) that emulated a 3540. It was the same drive as used for IML. We
also had one attached to our System-3/15D.

Tony Thigpen

R.S. wrote on 5/13/20 10:55 AM:

Excuse me, what is IBM 3540?
This is mainframe forum so I checked all historical DASD, including drum
device and 2305 (which is not a drum) and found no such device. I also
reviewed disks for small systems (S3 System 32, System 34... AS/400) and
still no such device. Finally I found ~500MB SCSI attached 3,5" disk
with such number.
However I still don't know what is 3540. Any clue?


Update: I found it. It is diskette (yes, 8" floppy diskette drive).
Where can I find the reference about it? In new shining z/OS 2.4 JCL
Reference!

Wow!


So, I dare to ask about this "still supported" device:
Was it Bus & Tag attached?
What parameters has the diskette? capacity, cylinders #, track length...
How it was recognized by operating system? Was it another DASD volume?
Every diskette was separate volume as tape cart?



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


What crashing COBOL systems reveal about applications maintenance -- GCN

2020-05-13 Thread Mark Regan
https://gcn.com/articles/2020/05/12/keeping-mainframes-up-to-date.aspx?m=1

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


Re: An older device query - still using??

2020-05-13 Thread William Donzelli
Bitsavers are the ones to do the scans, but currently all of the
scanning equipment is locked up in the closed museum (and driving Al
nuts). I can see if any of the other archivists could tackle the job.

But yes, you have goodies that would fill in some holes.

--
Will

On Wed, May 13, 2020 at 12:14 PM Seymour J Metz  wrote:
>
> If you're willing to pay the shipping, scan and OCR within a few months, I've 
> got hundreds of manuals, mostly IBM, that I'd be willing to give up in 
> exchange for sending me and bitsavers the PDF files.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> William Donzelli [wdonze...@gmail.com]
> Sent: Wednesday, May 13, 2020 11:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: An older device query - still using??
>
> Hey, that's my video. Go watch it!
>
> And remember, folks, I am always looking for this old stuff for the
> collection - mostly anything pre-Z (I set up that limit so I do not
> overcollect).
>
> Anything from a box of IBM indicator lights (thanks, recent donor!) to
> a 3090. I would make that happen.
>
> --
> Will
>
> On Wed, May 13, 2020 at 11:23 AM Parwez Hamid  
> wrote:
> >
> > The 3540 was a BUS & TAG attached device. I am not saying that its still in 
> > use by anyone. However, a while ago, during my travels I did find customers 
> > were using strange BUS and TAG devices with channel convertors etc.
> >
> > https://secure-web.cisco.com/1mtE7GVJOAzGIYFuFqh6r2mVx4dlsdCqJFKLtP-BE_NRdp0o136SQ2kteePdaAMkANW-1G_2I4UffM2S9YHQMDxloccnWCMSJQHvaJe15bcuNgUP5XDJ4moMCvAJ4gpm8pZddq2owyou4spOB_FpUyRt2ZUjTaKiPDMBKaaBVm_B2HNGsdHdLZudtpJ4VcPcIJlDz_WKGwsznjlABIaJzhgIoIErnLu5GNBaocG0OPuZGZ1d_v1EYySmZLgdh9RQiCTB6qOiEh0O8gEVCglLupFS9mgzbMmrPto-o9OzDyS4rquX-ewDNPSGcGSCnOLvcUgRo3OLShxJckXvh06fhl1-FQXZ5Mw61Dm-WqJEnNfYEVcgcOCvO3DkBEbxc_fqIaLJ1oy0hkj5daaSHYDb6c1aF8AsOKvVAUYy4YyHe19uAt_FyUTZbLRsWlGYfjjmZXCVSHZGalHH2AGXtFx4PGA/https%3A%2F%2Fwww.reddit.com%2Fr%2Fretrobattlestations%2Fcomments%2F627vtu%2Fbig_disk_week_ibm_3540_s370_channel_attached_8%2F
> > [https://secure-web.cisco.com/1r2YkZjH8aoOGoXpxhb3jByHB6ZR5GoHw4j7qlIzl95t5AjHavIFjUGtDi9A6nyMydIYRDag0kGYMLvtZG7SU_5ZAj0STR8MI3R6UMaaH7US2xmPA3cTUhmTkBoPG57eXeVYVM5YWK6_UA5Jc86zStgzUX_NyWuBMMnRop5MVHffxSgRGoBLzE5LBzG1mS2yfwJCd75rOszcRuRz9povyG_G4C77na9pJ40aORVAkVX8VDQL4ekFBBtCZxULnR4qECdTxuVUcq9tDrinXjyodnkr_qVrrHEE0QX7HyrPOWlKSgWB0O3WjPQ9dAgpTqp9Y5rFm12XgJi9wz0AtZBPBR8gqO-hMINyrz_qkjOZpPIP83kkY54bUMzwo19o9RPL_b3XnzYIFd7_kok781_7kuO50zoilAhpHwFMpSF7yQaT3vmh8j1KyCHv0R1QPMtxAVj9ILrd4vYxntkcfnjJG2w/https%3A%2F%2Fpreview.redd.it%2F1wgw7b1vndoy.jpg%3Fauto%3Dwebp%26s%3D700536458793462d84bccdfbea463e2ff9ccfc59%5D
> > [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive : 
> > retrobattlestations
> > [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive. Big Disk 
> > Week. Close. 30. Posted by. u/uniservo. 2 years ago. Archived [Big Disk 
> > Week] IBM 3540 S/370 channel attached 8" floppy drive. Big Disk Week. 10 
> > comments. share. save hide report. 98% Upvoted. This thread is archived. 
> > New comments cannot be posted and votes cannot be cast ...
> > 

Re: An older device query - still using??

2020-05-13 Thread Seymour J Metz
How do you emulate an input hopper? The 3540 wasn't a simple 8" floppy drive; 
it had a feeder so you could read a string of diskettes with no manual 
intervention between them.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Wednesday, May 13, 2020 11:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

The 4331 had an internal diskette drive (accessed from the top of the
cpu) that emulated a 3540. It was the same drive as used for IML. We
also had one attached to our System-3/15D.

Tony Thigpen

R.S. wrote on 5/13/20 10:55 AM:
> Excuse me, what is IBM 3540?
> This is mainframe forum so I checked all historical DASD, including drum
> device and 2305 (which is not a drum) and found no such device. I also
> reviewed disks for small systems (S3 System 32, System 34... AS/400) and
> still no such device. Finally I found ~500MB SCSI attached 3,5" disk
> with such number.
> However I still don't know what is 3540. Any clue?
>
>
> Update: I found it. It is diskette (yes, 8" floppy diskette drive).
> Where can I find the reference about it? In new shining z/OS 2.4 JCL
> Reference!
>
> Wow!
>
>
> So, I dare to ask about this "still supported" device:
> Was it Bus & Tag attached?
> What parameters has the diskette? capacity, cylinders #, track length...
> How it was recognized by operating system? Was it another DASD volume?
> Every diskette was separate volume as tape cart?
>

--
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: An older device query - still using??

2020-05-13 Thread Seymour J Metz
If you're willing to pay the shipping, scan and OCR within a few months, I've 
got hundreds of manuals, mostly IBM, that I'd be willing to give up in exchange 
for sending me and bitsavers the PDF files.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
William Donzelli [wdonze...@gmail.com]
Sent: Wednesday, May 13, 2020 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

Hey, that's my video. Go watch it!

And remember, folks, I am always looking for this old stuff for the
collection - mostly anything pre-Z (I set up that limit so I do not
overcollect).

Anything from a box of IBM indicator lights (thanks, recent donor!) to
a 3090. I would make that happen.

--
Will

On Wed, May 13, 2020 at 11:23 AM Parwez Hamid  wrote:
>
> The 3540 was a BUS & TAG attached device. I am not saying that its still in 
> use by anyone. However, a while ago, during my travels I did find customers 
> were using strange BUS and TAG devices with channel convertors etc.
>
> https://secure-web.cisco.com/1mtE7GVJOAzGIYFuFqh6r2mVx4dlsdCqJFKLtP-BE_NRdp0o136SQ2kteePdaAMkANW-1G_2I4UffM2S9YHQMDxloccnWCMSJQHvaJe15bcuNgUP5XDJ4moMCvAJ4gpm8pZddq2owyou4spOB_FpUyRt2ZUjTaKiPDMBKaaBVm_B2HNGsdHdLZudtpJ4VcPcIJlDz_WKGwsznjlABIaJzhgIoIErnLu5GNBaocG0OPuZGZ1d_v1EYySmZLgdh9RQiCTB6qOiEh0O8gEVCglLupFS9mgzbMmrPto-o9OzDyS4rquX-ewDNPSGcGSCnOLvcUgRo3OLShxJckXvh06fhl1-FQXZ5Mw61Dm-WqJEnNfYEVcgcOCvO3DkBEbxc_fqIaLJ1oy0hkj5daaSHYDb6c1aF8AsOKvVAUYy4YyHe19uAt_FyUTZbLRsWlGYfjjmZXCVSHZGalHH2AGXtFx4PGA/https%3A%2F%2Fwww.reddit.com%2Fr%2Fretrobattlestations%2Fcomments%2F627vtu%2Fbig_disk_week_ibm_3540_s370_channel_attached_8%2F
> [https://secure-web.cisco.com/1r2YkZjH8aoOGoXpxhb3jByHB6ZR5GoHw4j7qlIzl95t5AjHavIFjUGtDi9A6nyMydIYRDag0kGYMLvtZG7SU_5ZAj0STR8MI3R6UMaaH7US2xmPA3cTUhmTkBoPG57eXeVYVM5YWK6_UA5Jc86zStgzUX_NyWuBMMnRop5MVHffxSgRGoBLzE5LBzG1mS2yfwJCd75rOszcRuRz9povyG_G4C77na9pJ40aORVAkVX8VDQL4ekFBBtCZxULnR4qECdTxuVUcq9tDrinXjyodnkr_qVrrHEE0QX7HyrPOWlKSgWB0O3WjPQ9dAgpTqp9Y5rFm12XgJi9wz0AtZBPBR8gqO-hMINyrz_qkjOZpPIP83kkY54bUMzwo19o9RPL_b3XnzYIFd7_kok781_7kuO50zoilAhpHwFMpSF7yQaT3vmh8j1KyCHv0R1QPMtxAVj9ILrd4vYxntkcfnjJG2w/https%3A%2F%2Fpreview.redd.it%2F1wgw7b1vndoy.jpg%3Fauto%3Dwebp%26s%3D700536458793462d84bccdfbea463e2ff9ccfc59%5D
> [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive : 
> retrobattlestations
> [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive. Big Disk 
> Week. Close. 30. Posted by. u/uniservo. 2 years ago. Archived [Big Disk Week] 
> IBM 3540 S/370 channel attached 8" floppy drive. Big Disk Week. 10 comments. 
> share. save hide report. 98% Upvoted. This thread is archived. New comments 
> cannot be posted and votes cannot be cast ...
> http://secure-web.cisco.com/15EeihPYXHZ_AVdzr8FA2V6KcvpgxOrNDL_M2k1cQc1vXxFIC8f4MC4RUCq_0GKwk5DJmEadjq938ROKnGbhmX4gfICgv2OWh4Q7Cqft_ASBNbvqg3nON7ayc63S-aldlqh4MDMDhw3ljcbnFx4I0pZ7yomuxdn0UQfu5w-UrpMDO085ISVEPYLYtfYfK6LRanRK2ntZzPXb8beaAzalRN6ovayEyaojmYQzlZEqeK2aYKXcm4bDtExcoOTJf8ReAcJhQ2ZoT-7o1GUBQnDisNZsLS_N1EndNzVNTAPRIqa7ySR_DxLRpPhKwP3jo1WHveoG2OO4xUsY1dI7WsLJqtcWNBjTqyEb5FJLma7HAK13PeHt4m8wbfJcYW56XlGOo9pqZyoQiPhrErBSifCVrZwb8-f2QoY10nf5Oqffk6noTCZCN0DmGTZZ0yC9S_vgOTiB0L5azUOKdQVNIrP9QqA/http%3A%2F%2Fwww.reddit.com
>
>
> Regards
>
> Parwez Hamid
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> R.S. 
> Sent: 13 May 2020 15:55
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: An older device query - still using??
>
> Excuse me, what is IBM 3540?
> This is mainframe forum so I checked all historical DASD, including drum
> device and 2305 (which is 

Re: An older device query - still using??

2020-05-13 Thread William Donzelli
Hey, that's my video. Go watch it!

And remember, folks, I am always looking for this old stuff for the
collection - mostly anything pre-Z (I set up that limit so I do not
overcollect).

Anything from a box of IBM indicator lights (thanks, recent donor!) to
a 3090. I would make that happen.

--
Will

On Wed, May 13, 2020 at 11:23 AM Parwez Hamid  wrote:
>
> The 3540 was a BUS & TAG attached device. I am not saying that its still in 
> use by anyone. However, a while ago, during my travels I did find customers 
> were using strange BUS and TAG devices with channel convertors etc.
>
> https://www.reddit.com/r/retrobattlestations/comments/627vtu/big_disk_week_ibm_3540_s370_channel_attached_8/
> [https://preview.redd.it/1wgw7b1vndoy.jpg?auto=webp=700536458793462d84bccdfbea463e2ff9ccfc59]
> [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive : 
> retrobattlestations
> [Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive. Big Disk 
> Week. Close. 30. Posted by. u/uniservo. 2 years ago. Archived [Big Disk Week] 
> IBM 3540 S/370 channel attached 8" floppy drive. Big Disk Week. 10 comments. 
> share. save hide report. 98% Upvoted. This thread is archived. New comments 
> cannot be posted and votes cannot be cast ...
> www.reddit.com
>
>
> Regards
>
> Parwez Hamid
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> R.S. 
> Sent: 13 May 2020 15:55
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: An older device query - still using??
>
> Excuse me, what is IBM 3540?
> This is mainframe forum so I checked all historical DASD, including drum
> device and 2305 (which is not a drum) and found no such device. I also
> reviewed disks for small systems (S3 System 32, System 34... AS/400) and
> still no such device. Finally I found ~500MB SCSI attached 3,5" disk
> with such number.
> However I still don't know what is 3540. Any clue?
>
>
> Update: I found it. It is diskette (yes, 8" floppy diskette drive).
> Where can I find the reference about it? In new shining z/OS 2.4 JCL
> Reference!
>
> Wow!
>
>
> So, I dare to ask about this "still supported" device:
> Was it Bus & Tag attached?
> What parameters has the diskette? capacity, cylinders #, track length...
> How it was recognized by operating system? Was it another DASD volume?
> Every diskette was separate volume as tape cart?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 12.05.2020 o 21:40, Marna WALLE pisze:
> > Hello All,
> > We had an internal small discussion wondering if there were any customers 
> > that still used these devices (the youngest of which went end-of-service in 
> > 2014, from what I can find).  I wanted to extend this conversation outside 
> > of IBM, to those that might have firsthand current knowledge.
> >
> > Here's the devices I'm wondering about:
> >
> > 1287/1288 - IBM Optical reader and page reader respectively
> > 3540 - IBM Disk device
> > 3886 - IBM Optical Character reader
> > 3890 - IBM Magnetic Ink Reader
> > 3895 - IBM Printer device
> >
> > If you or someone you know *currently* has one of the above devices in use, 
> > would you mind contacting me?  I'm not interested in the past, when I know 
> > these were once-popular devices. For instance, all LinkedIn hits I read 
> > were all "prior experience" type of references.
> >
> > I'm interested in current 2020 usage of them.  I appreciate learning about 
> > this.
> > -Marna WALLE
> > z/OS Installation, IBM Poughkeepsie
> > mwa...@us.ibm.com
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > .
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub 
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może 
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia 
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza 
> prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
> Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
> NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies 

Re: Colossus, Strangelove, etc. was: Developers say...

2020-05-13 Thread scott Ford
Russell:

Yep , exactly, AI's that develop themselves , think Person of Interest ,
had a list of all the social security numbers of people that needed help
and at Midnight did a complete refresh of that list.
A very interesting concept.

Scott

On Mon, May 11, 2020 at 10:06 PM Seymour J Metz  wrote:

> Well, Heinlein's explanation was bafflegab, but think neural nets; they
> have to be trained rather than programmed.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Russell Witt [025adb32e6d7-dmarc-requ...@listserv.ua.edu]
> Sent: Monday, May 11, 2020 9:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Colossus, Strangelove, etc. was: Developers say...
>
> But what about the AI that develops autonomously? Remember Mike (Mycroft)
> from The Moon is a Harsh Mistress (Heinlein) and TANSTAAFL (still true
> today - so many people forget). AI might not be "developed" directly, which
> then rules out having any "rules".
>
> Russell
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of scott Ford
> Sent: Monday, May 11, 2020 10:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Colossus, Strangelove, etc. was: Developers say...
>
> Joel,
>
> I agree I am a huge sci-fi fan and believe in the sciences over utter
> stupidity.
> Lionel your point is well taken. I am guilty too, but when you have strong
> feelings , which sometimes part of ADHD , it’s called RSD ( Reject
> Sensitive Dysphoria ).
> I have both ...
>
> Scott
>
> On Mon, May 11, 2020 at 11:22 AM Lionel B Dyck  wrote:
>
> > Joel - can we please keep politics out of this listserv. Personally I
> > wouldn't trust anyone in power to act against their own self interests
> > and that applies to politicians and anyone else with power (as in
> > money, influence, etc.).
> >
> > There are altruistic individuals in the world and when it comes to the
> > development of an AI robot one prays/hopes that those are the software
> > developers who implement the code for the three laws.
> >
> >
> > Lionel B. Dyck <
> > Website:
> https://secure-web.cisco.com/10rW9HRt3rzwxzpQwZHaIaC_lBpBXktWnjqey9MYD8CTNRZehiZ-cQm-wjOlPtpza0yh2Q10-0KdT_XcArRjoeQ2nMiLt61252ye4hPTKFuPXgrYELwQ54ioOLkR-FEGH68FsHXY145RqiE1b97NrhE7o2clkfWGlhPy4F22jGvW6jjJwZoNwOx_dD5DdA6cOy-OO7TwEgYNdCD5EJ4IN51GSWLIYW-JGV4c_TaAon7_kL_nRItaZXmspnf7KySHBu5WuvaH4pKwaq4YARZjZT50Ltdv63kKUvQ72XSRiO7-aCszqGoWi4CU0gh--4qDLpQsD5sQH0UhbJfJkZKPzfZoGfFDT12X_BzTNKk0CYbrB-yKyMQlyr3pXTBSYUcc74hMt2il56Km4CzPi85cLM1YuDxBMjeMeZMa1sXtneJ86iw1PpGfx__Tkz8En7xH8/https%3A%2F%2Fwww.lbdsoftware.com
> >
> > "Worry more about your character than your reputation.  Character is
> > what you are, reputation merely what others think you are." - John
> > Wooden
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Joel C. Ewing
> > Sent: Monday, May 11, 2020 10:12 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Colossus, Strangelove, etc. was: Developers say...
> >
> > I've greatly enjoyed Asimov's vision of future possibilities, but when
> > I step back to reality it occurs to me that his perfect laws of
> > robotics would have to be implemented by fallible human programmers.
> > Even if well-intentioned, how would they unambiguously convey to a
> > robot the concepts of "human", "humanity", "hurt", and "injure" when
> > there have always been minorities or "others" that are treated by one
> > group of humans as sub-human to justify injuring them in the name of
> "protecting"
> > them or protecting humanity?  And then there is the issue of who might
> > make the decision to build sentient robots:   For example, who in our
> > present White House would you trust to pay any heed to logic or
> > scientific recommendations or long-term consequences, if they were
> > given the opportunity to construct less-constrained AI robots that
> > they perceived offered some short-term political advantage?
> >
> > Humanity was also fortunate that when the hardware of Asimov's Daneel
> > began to fail, that he failed gracefully, rather than becoming a
> > menace to humanity.
> > Joel C Ewing
> >
> > On 5/11/20 8:43 AM, scott Ford wrote:
> > > Well done JoelI agree , But I can help to to be curious about
> > > the future of AI.
> > > a bit of Isaac Asimov 
> > >
> > > Scott
> > >
> > > On Mon, May 11, 2020 at 9:25 AM Joel C. Ewing  wrote:
> > >
> > >> And of course the whole point of Colossus, Dr Strangelove, War
> > >> Games, Terminator,  Forbidden Planet, Battlestar Galactica, etc.
> > >> was to try to make it clear to all the non-engineers and
> > >> non-programmers (all of whom greatly outnumber us) why putting
> > >> lethal force in the hands of any autonomous or even semi-autonomous
> > >> machine is something with incredible potential to go wrong.  We all
> > >> know that even if the 

Re: An older device query - still using??

2020-05-13 Thread Tony Thigpen
The 4331 had an internal diskette drive (accessed from the top of the 
cpu) that emulated a 3540. It was the same drive as used for IML. We 
also had one attached to our System-3/15D.


Tony Thigpen

R.S. wrote on 5/13/20 10:55 AM:

Excuse me, what is IBM 3540?
This is mainframe forum so I checked all historical DASD, including drum 
device and 2305 (which is not a drum) and found no such device. I also 
reviewed disks for small systems (S3 System 32, System 34... AS/400) and 
still no such device. Finally I found ~500MB SCSI attached 3,5" disk 
with such number.

However I still don't know what is 3540. Any clue?


Update: I found it. It is diskette (yes, 8" floppy diskette drive).
Where can I find the reference about it? In new shining z/OS 2.4 JCL 
Reference!


Wow!


So, I dare to ask about this "still supported" device:
Was it Bus & Tag attached?
What parameters has the diskette? capacity, cylinders #, track length...
How it was recognized by operating system? Was it another DASD volume?
Every diskette was separate volume as tape cart?



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


Re: An older device query - still using??

2020-05-13 Thread Parwez Hamid
The 3540 was a BUS & TAG attached device. I am not saying that its still in use 
by anyone. However, a while ago, during my travels I did find customers were 
using strange BUS and TAG devices with channel convertors etc.

https://www.reddit.com/r/retrobattlestations/comments/627vtu/big_disk_week_ibm_3540_s370_channel_attached_8/
[https://preview.redd.it/1wgw7b1vndoy.jpg?auto=webp=700536458793462d84bccdfbea463e2ff9ccfc59]
[Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive : 
retrobattlestations
[Big Disk Week] IBM 3540 S/370 channel attached 8" floppy drive. Big Disk Week. 
Close. 30. Posted by. u/uniservo. 2 years ago. Archived [Big Disk Week] IBM 
3540 S/370 channel attached 8" floppy drive. Big Disk Week. 10 comments. share. 
save hide report. 98% Upvoted. This thread is archived. New comments cannot be 
posted and votes cannot be cast ...
www.reddit.com


Regards

Parwez Hamid​


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: 13 May 2020 15:55
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: An older device query - still using??

Excuse me, what is IBM 3540?
This is mainframe forum so I checked all historical DASD, including drum
device and 2305 (which is not a drum) and found no such device. I also
reviewed disks for small systems (S3 System 32, System 34... AS/400) and
still no such device. Finally I found ~500MB SCSI attached 3,5" disk
with such number.
However I still don't know what is 3540. Any clue?


Update: I found it. It is diskette (yes, 8" floppy diskette drive).
Where can I find the reference about it? In new shining z/OS 2.4 JCL
Reference!

Wow!


So, I dare to ask about this "still supported" device:
Was it Bus & Tag attached?
What parameters has the diskette? capacity, cylinders #, track length...
How it was recognized by operating system? Was it another DASD volume?
Every diskette was separate volume as tape cart?

--
Radoslaw Skorupka
Lodz, Poland






W dniu 12.05.2020 o 21:40, Marna WALLE pisze:
> Hello All,
> We had an internal small discussion wondering if there were any customers 
> that still used these devices (the youngest of which went end-of-service in 
> 2014, from what I can find).  I wanted to extend this conversation outside of 
> IBM, to those that might have firsthand current knowledge.
>
> Here's the devices I'm wondering about:
>
> 1287/1288 - IBM Optical reader and page reader respectively
> 3540 - IBM Disk device
> 3886 - IBM Optical Character reader
> 3890 - IBM Magnetic Ink Reader
> 3895 - IBM Printer device
>
> If you or someone you know *currently* has one of the above devices in use, 
> would you mind contacting me?  I'm not interested in the past, when I know 
> these were once-popular devices. For instance, all LinkedIn hits I read were 
> all "prior experience" type of references.
>
> I'm interested in current 2020 usage of them.  I appreciate learning about 
> this.
> -Marna WALLE
> z/OS Installation, IBM Poughkeepsie
> mwa...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .



==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 

Re: An older device query - still using??

2020-05-13 Thread Seymour J Metz
Bus and tag is all there was when the 3540 was current. You generated it as a 
unit record device.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
R.S. [r.skoru...@bremultibank.com.pl]
Sent: Wednesday, May 13, 2020 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

Excuse me, what is IBM 3540?
This is mainframe forum so I checked all historical DASD, including drum
device and 2305 (which is not a drum) and found no such device. I also
reviewed disks for small systems (S3 System 32, System 34... AS/400) and
still no such device. Finally I found ~500MB SCSI attached 3,5" disk
with such number.
However I still don't know what is 3540. Any clue?


Update: I found it. It is diskette (yes, 8" floppy diskette drive).
Where can I find the reference about it? In new shining z/OS 2.4 JCL
Reference!

Wow!


So, I dare to ask about this "still supported" device:
Was it Bus & Tag attached?
What parameters has the diskette? capacity, cylinders #, track length...
How it was recognized by operating system? Was it another DASD volume?
Every diskette was separate volume as tape cart?

--
Radoslaw Skorupka
Lodz, Poland






W dniu 12.05.2020 o 21:40, Marna WALLE pisze:
> Hello All,
> We had an internal small discussion wondering if there were any customers 
> that still used these devices (the youngest of which went end-of-service in 
> 2014, from what I can find).  I wanted to extend this conversation outside of 
> IBM, to those that might have firsthand current knowledge.
>
> Here's the devices I'm wondering about:
>
> 1287/1288 - IBM Optical reader and page reader respectively
> 3540 - IBM Disk device
> 3886 - IBM Optical Character reader
> 3890 - IBM Magnetic Ink Reader
> 3895 - IBM Printer device
>
> If you or someone you know *currently* has one of the above devices in use, 
> would you mind contacting me?  I'm not interested in the past, when I know 
> these were once-popular devices. For instance, all LinkedIn hits I read were 
> all "prior experience" type of references.
>
> I'm interested in current 2020 usage of them.  I appreciate learning about 
> this.
> -Marna WALLE
> z/OS Installation, IBM Poughkeepsie
> mwa...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .



==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1U_kQ3M9MePvCfK7czR2oFLX265-bYJp-wtYQwx7dbc74-q5xaFur6dNzXdaVFeLGhXRPluLA5T-tR0x7MRii24UMjNFt8kqiBpvGSY2XT_Doy8sHNoQceef_HpUQbBeMO0LbBd5CSBKwxsZSGbTgtUtCOc3jIzufAQugjkGjjPrHqXxluDr9-qsOQoDkP-YIy6xTjcRSQdOH_pTpM4Zz_l5wXyHz-N1-kjyBUxxXgcTTS7EFIRnCVZxENj3k_kqVyZOAEODZsjlnGTX54MnjoKlDQYfOCOQ5U-MJeLI0VrZ-Hv50lh8-g9sAcAlQLM1gHI9bABdjBJtaicVDhiUMfLAx8VNao0DvhlQRK8wm70QmlNCew1sVVhzxUl-tq9-5_A3w32bW6cPfFjzRTcTaSP-uyerPWng_y2m4m6iAKmohbIhLDSRr0DUhAx0G_pBB8fIscNuwGjrNiE27t4JNQg/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 
169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1U_kQ3M9MePvCfK7czR2oFLX265-bYJp-wtYQwx7dbc74-q5xaFur6dNzXdaVFeLGhXRPluLA5T-tR0x7MRii24UMjNFt8kqiBpvGSY2XT_Doy8sHNoQceef_HpUQbBeMO0LbBd5CSBKwxsZSGbTgtUtCOc3jIzufAQugjkGjjPrHqXxluDr9-qsOQoDkP-YIy6xTjcRSQdOH_pTpM4Zz_l5wXyHz-N1-kjyBUxxXgcTTS7EFIRnCVZxENj3k_kqVyZOAEODZsjlnGTX54MnjoKlDQYfOCOQ5U-MJeLI0VrZ-Hv50lh8-g9sAcAlQLM1gHI9bABdjBJtaicVDhiUMfLAx8VNao0DvhlQRK8wm70QmlNCew1sVVhzxUl-tq9-5_A3w32bW6cPfFjzRTcTaSP-uyerPWng_y2m4m6iAKmohbIhLDSRr0DUhAx0G_pBB8fIscNuwGjrNiE27t4JNQg/http%3A%2F%2Fwww.mBank.pl,
 e-mail: 

Re: An older device query - still using??

2020-05-13 Thread R.S.

Excuse me, what is IBM 3540?
This is mainframe forum so I checked all historical DASD, including drum 
device and 2305 (which is not a drum) and found no such device. I also 
reviewed disks for small systems (S3 System 32, System 34... AS/400) and 
still no such device. Finally I found ~500MB SCSI attached 3,5" disk 
with such number.

However I still don't know what is 3540. Any clue?


Update: I found it. It is diskette (yes, 8" floppy diskette drive).
Where can I find the reference about it? In new shining z/OS 2.4 JCL 
Reference!


Wow!


So, I dare to ask about this "still supported" device:
Was it Bus & Tag attached?
What parameters has the diskette? capacity, cylinders #, track length...
How it was recognized by operating system? Was it another DASD volume?
Every diskette was separate volume as tape cart?

--
Radoslaw Skorupka
Lodz, Poland






W dniu 12.05.2020 o 21:40, Marna WALLE pisze:

Hello All,
We had an internal small discussion wondering if there were any customers that 
still used these devices (the youngest of which went end-of-service in 2014, 
from what I can find).  I wanted to extend this conversation outside of IBM, to 
those that might have firsthand current knowledge.

Here's the devices I'm wondering about:

1287/1288 - IBM Optical reader and page reader respectively
3540 - IBM Disk device
3886 - IBM Optical Character reader
3890 - IBM Magnetic Ink Reader
3895 - IBM Printer device

If you or someone you know *currently* has one of the above devices in use, would you 
mind contacting me?  I'm not interested in the past, when I know these were once-popular 
devices. For instance, all LinkedIn hits I read were all "prior experience" 
type of references.

I'm interested in current 2020 usage of them.  I appreciate learning about this.
-Marna WALLE
z/OS Installation, IBM Poughkeepsie
mwa...@us.ibm.com

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




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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


Re: zOSMF - The PORT will not OPEN

2020-05-13 Thread Ken Smith
/global/zosmf   Contains customer configuration and output. Read/write

/usr/lpp/zosmf/  IBM software. Read/only for cross system sharing and to
prevent updates by misconfiguration.

Any other setup is incorrect.

On Wed, May 13, 2020 at 10:25 AM Carmen Vitullo  wrote:

> the /global/ directory is for KC data files, books and zosmf customer data
> there is no lib directory there , not suppose to be
>
>
> these are the directories off /global/zosmf
>
>
>
> configuration
> data
> logs
>
> if you still have an untouched SMP/E ir ServerPac root you can copy from
> there, copy the entire serverpac root, but mount it first and check that
> its complete
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Steve Beaver" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Wednesday, May 13, 2020 9:10:49 AM
> Subject: Re: zOSMF - The PORT will not OPEN
>
> I found that file in my /global/zosmf/lib and there are 47 files there
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Wednesday, May 13, 2020 8:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: zOSMF - The PORT will not OPEN
>
> Steve,
>
> How many files do you see at /usr/lpp/zosmf/lib? On my system there are
> 47,
> including the file you are missing libIzuCommandJni.so
>
> 
>
> _
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank | 1830 East Paris Ave, SE
> 
> | MD RSCB2H | Grand Rapids,
> MI 49546
> 616.653.8429 | fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of
> Steve Beaver
> Sent: Wednesday, May 13, 2020 9:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: zOSMF - The PORT will not OPEN
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> Has anyone seen this error before out of zOSMF. The PORT will not OPEN
>
>
>
> ÝERROR ¨ CWWKE0701E: bundle
> com.ibm.zoszmf.command.management:1.0.0.qualifier
> (166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
>
> 27) ¨ : The activate method has thrown an exception
> java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
> (EDC5205S DLL module not found. (errno2=0xC40B0025)) at
> java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425)
> at java.lang.System.load(System.java:552)
> at
> com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat
>
> e(UserProductExtensionCommandHandler.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90
>
> )
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
>
> .java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.
>
> java:242)
> at Ýinternal classes¨
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
> EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged. It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it
> in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the
> sender
> that the message was misdirected. After replying, please erase it from
> your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@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: zOSMF - The PORT will not OPEN

2020-05-13 Thread Jousma, David
I misspoke, there is a configuration directory in both locations.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: Jousma, David 
Sent: Wednesday, May 13, 2020 10:32 AM
To: IBM Mainframe Discussion List 
Subject: RE: zOSMF - The PORT will not OPEN

With the exception of configuration and data, all the others are in 
/usr/lpp/zosmf on my V2.4 systems.

TEC1:$ cd /usr/lpp/zosmf
 
TEC1:$ ls -al   
 
total 384   
 
drwxr-xr-x  13 P0SJROMVSGRP 8192 Jan 24 07:03 . 
 
drwxr-xr-x  42 P0SJROMVSGRP 8192 Oct 22  2019 ..
 
drwxr-xr-x   2 P0SJROMVSGRP 8192 Dec 17 08:27 IBM   
 
drwxr-xr-x   2 P0SJROMVSGRP 8192 Feb 10 14:09 bin   
 
drwxr-xr-x   3 P0SJROMVSGRP 8192 Jan 10 14:20 configuration 
 
drwxr-xr-x   4 P0SJROMVSGRP 8192 Jan 24 07:04 defaults  
 
drwxr-xr-x   3 P0SJROMVSGRP 8192 Sep 25  2019 helps 
 
drwxr-xr-x  22 P0SJROMVSGRP 8192 Apr  9 14:39 installableApps   
 
drwxr-xr-x   3 P0SJROMVSGRP 8192 May 14  2014 kc
 
drwxr-xr-x   2 P0SJROMVSGRP 8192 Apr  8 07:08 lib   
 
lrwxrwxrwx   1 P0SJROMVSGRP   22 Jan 24 07:03 liberty -> 
../liberty_zos/current  
drwxr-xr-x   4 P0SJROMVSGRP 8192 Dec 17 08:27 samples   
 
drwxr-xr-x   2 P0SJROMVSGRP 8192 Mar 11  2019 wlp   
 
drwxr-xr-x   5 P0SJROMVSGRP 8192 Dec 17 08:27 workflow  
 
-rwxr-xr-x   2 P0SJROMVSGRP81304 Dec 10 09:37 zosmf_license.README  
 
TEC1:$  
 

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Bin  configuration data defaults helps IBM InstallableApps kc lib liberty logs 
samples workflow zosmf_license.READMR

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, May 13, 2020 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

You (or someone else) have evidentially done some unnatural acts.   There
should only be two directories in your /global/zosmf directory, configuration, 
and data


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I found that file in my /global/zosmf/lib and there are 47 files there

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, May 13, 2020 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

How many files do you see at /usr/lpp/zosmf/lib?  On my system there are 47, 
including the file you are missing  libIzuCommandJni.so


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - The PORT will not OPEN


Re: zOSMF - The PORT will not OPEN

2020-05-13 Thread Jousma, David
With the exception of configuration and data, all the others are in 
/usr/lpp/zosmf on my V2.4 systems.

TEC1:$ cd /usr/lpp/zosmf
 
TEC1:$ ls -al   
 
total 384   
 
drwxr-xr-x  13 P0SJROMVSGRP 8192 Jan 24 07:03 . 
 
drwxr-xr-x  42 P0SJROMVSGRP 8192 Oct 22  2019 ..
 
drwxr-xr-x   2 P0SJROMVSGRP 8192 Dec 17 08:27 IBM   
 
drwxr-xr-x   2 P0SJROMVSGRP 8192 Feb 10 14:09 bin   
 
drwxr-xr-x   3 P0SJROMVSGRP 8192 Jan 10 14:20 configuration 
 
drwxr-xr-x   4 P0SJROMVSGRP 8192 Jan 24 07:04 defaults  
 
drwxr-xr-x   3 P0SJROMVSGRP 8192 Sep 25  2019 helps 
 
drwxr-xr-x  22 P0SJROMVSGRP 8192 Apr  9 14:39 installableApps   
 
drwxr-xr-x   3 P0SJROMVSGRP 8192 May 14  2014 kc
 
drwxr-xr-x   2 P0SJROMVSGRP 8192 Apr  8 07:08 lib   
 
lrwxrwxrwx   1 P0SJROMVSGRP   22 Jan 24 07:03 liberty -> 
../liberty_zos/current  
drwxr-xr-x   4 P0SJROMVSGRP 8192 Dec 17 08:27 samples   
 
drwxr-xr-x   2 P0SJROMVSGRP 8192 Mar 11  2019 wlp   
 
drwxr-xr-x   5 P0SJROMVSGRP 8192 Dec 17 08:27 workflow  
 
-rwxr-xr-x   2 P0SJROMVSGRP81304 Dec 10 09:37 zosmf_license.README  
 
TEC1:$  
 

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Bin  configuration data defaults helps IBM InstallableApps kc lib liberty logs 
samples workflow zosmf_license.READMR

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, May 13, 2020 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

You (or someone else) have evidentially done some unnatural acts.   There
should only be two directories in your /global/zosmf directory, configuration, 
and data


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I found that file in my /global/zosmf/lib and there are 47 files there

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, May 13, 2020 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

How many files do you see at /usr/lpp/zosmf/lib?  On my system there are 47, 
including the file you are missing  libIzuCommandJni.so


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Has anyone seen this error before out of zOSMF.  The PORT will not OPEN

 

ÝERROR   ¨ CWWKE0701E: bundle
com.ibm.zoszmf.command.management:1.0.0.qualifier
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
27) ¨ : The activate method has thrown an exception
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
(EDC5205S DLL module not found. 

Re: zOSMF - The PORT will not OPEN

2020-05-13 Thread Steve Beaver
Bin  configuration data defaults helps IBM InstallableApps kc lib liberty
logs samples workflow zosmf_license.READMR

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, May 13, 2020 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

You (or someone else) have evidentially done some unnatural acts.   There
should only be two directories in your /global/zosmf directory,
configuration, and data


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, May 13, 2020 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

I found that file in my /global/zosmf/lib and there are 47 files there

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, May 13, 2020 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

How many files do you see at /usr/lpp/zosmf/lib?  On my system there are 47,
including the file you are missing  libIzuCommandJni.so


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, May 13, 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Has anyone seen this error before out of zOSMF.  The PORT will not OPEN

 

ÝERROR   ¨ CWWKE0701E: bundle
com.ibm.zoszmf.command.management:1.0.0.qualifier
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
27) ¨ : The activate method has thrown an exception
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425)
at java.lang.System.load(System.java:552)
at
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat
e(UserProductExtensionCommandHandler.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.
java:242)
at Ýinternal classes¨






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

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@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 **CAUTION
EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the 

Re: zOSMF - The PORT will not OPEN

2020-05-13 Thread Carmen Vitullo
the /global/ directory is for KC data files, books and zosmf customer data 
there is no lib directory there , not suppose to be 


these are the directories off /global/zosmf 



configuration 
data 
logs 

if you still have an untouched SMP/E ir ServerPac root you can copy from there, 
copy the entire serverpac root, but mount it first and check that its complete 


Carmen Vitullo 

- Original Message -

From: "Steve Beaver"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 13, 2020 9:10:49 AM 
Subject: Re: zOSMF - The PORT will not OPEN 

I found that file in my /global/zosmf/lib and there are 47 files there 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Jousma, David 
Sent: Wednesday, May 13, 2020 8:46 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zOSMF - The PORT will not OPEN 

Steve, 

How many files do you see at /usr/lpp/zosmf/lib? On my system there are 47, 
including the file you are missing libIzuCommandJni.so 

 
_ 
Dave Jousma 
AVP | Manager, Systems Engineering 

Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, 
MI 49546 
616.653.8429 | fax: 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver 
Sent: Wednesday, May 13, 2020 9:41 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: zOSMF - The PORT will not OPEN 

**CAUTION EXTERNAL EMAIL** 

**DO NOT open attachments or click on links from unknown senders or 
unexpected emails** 

Has anyone seen this error before out of zOSMF. The PORT will not OPEN 



ÝERROR ¨ CWWKE0701E: bundle 
com.ibm.zoszmf.command.management:1.0.0.qualifier 
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4 
27) ¨ : The activate method has thrown an exception 
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so 
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at 
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425) 
at java.lang.System.load(System.java:552) 
at 
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat 
e(UserProductExtensionCommandHandler.java:141) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90 
) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl 
.java:55) 
at java.lang.reflect.Method.invoke(Method.java:508) 
at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod. 
java:242) 
at Ýinternal classes¨ 






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

**DO NOT open attachments or click on links from unknown senders or 
unexpected emails** 


This e-mail transmission contains information that is confidential and may 
be privileged. It is intended only for the addressee(s) named above. If 
you receive this e-mail in error, please do not read, copy or disseminate it 
in any manner. If you are not the intended recipient, any disclosure, 
copying, distribution or use of the contents of this information is 
prohibited. Please reply to the message immediately by informing the sender 
that the message was misdirected. After replying, please erase it from your 
computer system. Your assistance in correcting this error is appreciated. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@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: zOSMF - The PORT will not OPEN

2020-05-13 Thread Jousma, David
Steve,

You (or someone else) have evidentially done some unnatural acts.   There 
should only be two directories in your /global/zosmf directory, configuration, 
and data

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I found that file in my /global/zosmf/lib and there are 47 files there

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, May 13, 2020 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

How many files do you see at /usr/lpp/zosmf/lib?  On my system there are 47, 
including the file you are missing  libIzuCommandJni.so


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Has anyone seen this error before out of zOSMF.  The PORT will not OPEN

 

ÝERROR   ¨ CWWKE0701E: bundle
com.ibm.zoszmf.command.management:1.0.0.qualifier
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
27) ¨ : The activate method has thrown an exception
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425)
at java.lang.System.load(System.java:552)
at
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat
e(UserProductExtensionCommandHandler.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.
java:242)
at Ýinternal classes¨






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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it in 
any manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For 

Re: zOSMF - The PORT will not OPEN

2020-05-13 Thread Steve Beaver
I found that file in my /global/zosmf/lib and there are 47 files there

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, May 13, 2020 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

How many files do you see at /usr/lpp/zosmf/lib?  On my system there are 47,
including the file you are missing  libIzuCommandJni.so


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, May 13, 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Has anyone seen this error before out of zOSMF.  The PORT will not OPEN

 

ÝERROR   ¨ CWWKE0701E: bundle
com.ibm.zoszmf.command.management:1.0.0.qualifier
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
27) ¨ : The activate method has thrown an exception
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425)
at java.lang.System.load(System.java:552)
at
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat
e(UserProductExtensionCommandHandler.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.
java:242)
at Ýinternal classes¨






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

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@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: zOSMF - The PORT will not OPEN

2020-05-13 Thread Carmen Vitullo
so you still have your ServerPac or custompac root? 
if not mounted, mount it and check /usr/lpp/zosmf/lib 
on my maint root @ RSU2001 I have 44 files 



Carmen Vitullo 

- Original Message -

From: "Steve Beaver"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 13, 2020 9:00:23 AM 
Subject: Re: zOSMF - The PORT will not OPEN 

The filesystem is readonly 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Jousma, David 
Sent: Wednesday, May 13, 2020 8:58 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zOSMF - The PORT will not OPEN 

Well, there's the answer then. You seemed to have accidentally damaged 
your SMPE managed filesystem. You are likely to be chasing these kinds of 
problems on an ongoing basis. If you have other systems that are copies 
and you *know* matches your SMPE environment, you could rebuild that entire 
filesystem. Thenmy suggestion is mount read only. 

 
_ 
Dave Jousma 
AVP | Manager, Systems Engineering 

Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, 
MI 49546 
616.653.8429 | fax: 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver 
Sent: Wednesday, May 13, 2020 9:52 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zOSMF - The PORT will not OPEN 

**CAUTION EXTERNAL EMAIL** 

**DO NOT open attachments or click on links from unknown senders or 
unexpected emails** 

How amount NONE 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Jousma, David 
Sent: Wednesday, May 13, 2020 8:46 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zOSMF - The PORT will not OPEN 

Steve, 

How many files do you see at /usr/lpp/zosmf/lib? On my system there are 47, 
including the file you are missing libIzuCommandJni.so 

 
_ 
Dave Jousma 
AVP | Manager, Systems Engineering 

Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, 
MI 49546 
616.653.8429 | fax: 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver 
Sent: Wednesday, May 13, 2020 9:41 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: zOSMF - The PORT will not OPEN 

**CAUTION EXTERNAL EMAIL** 

**DO NOT open attachments or click on links from unknown senders or 
unexpected emails** 

Has anyone seen this error before out of zOSMF. The PORT will not OPEN 



ÝERROR ¨ CWWKE0701E: bundle 
com.ibm.zoszmf.command.management:1.0.0.qualifier 
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4 
27) ¨ : The activate method has thrown an exception 
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so 
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at 
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425) 
at java.lang.System.load(System.java:552) 
at 
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat 
e(UserProductExtensionCommandHandler.java:141) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90 
) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl 
.java:55) 
at java.lang.reflect.Method.invoke(Method.java:508) 
at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod. 
java:242) 
at Ýinternal classes¨ 






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

**DO NOT open attachments or click on links from unknown senders or 
unexpected emails** 


This e-mail transmission contains information that is confidential and may 
be privileged. It is intended only for the addressee(s) named above. If 
you receive this e-mail in error, please do not read, copy or disseminate it 
in any manner. If you are not the intended recipient, any disclosure, 
copying, distribution or use of the contents of this information is 
prohibited. Please reply to the message immediately by informing the sender 
that the message was misdirected. After replying, please erase it from your 
computer system. Your assistance in correcting this error is appreciated. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, send email 
to lists...@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 **CAUTION 

Re: zOSMF - The PORT will not OPEN

2020-05-13 Thread Steve Beaver
The filesystem is readonly 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, May 13, 2020 8:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Well, there's the answer then.   You seemed to have accidentally damaged
your SMPE managed filesystem.   You are likely to be chasing these kinds of
problems on an ongoing basis.   If you have other systems that are copies
and you *know* matches your SMPE environment, you could rebuild that entire
filesystem.   Thenmy suggestion is mount read only.


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, May 13, 2020 9:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

How amount NONE

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, May 13, 2020 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

How many files do you see at /usr/lpp/zosmf/lib?  On my system there are 47,
including the file you are missing  libIzuCommandJni.so


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, May 13, 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Has anyone seen this error before out of zOSMF.  The PORT will not OPEN

 

ÝERROR   ¨ CWWKE0701E: bundle
com.ibm.zoszmf.command.management:1.0.0.qualifier
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
27) ¨ : The activate method has thrown an exception
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425)
at java.lang.System.load(System.java:552)
at
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat
e(UserProductExtensionCommandHandler.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.
java:242)
at Ýinternal classes¨






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

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@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 **CAUTION
EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,

Re: zOSMF - The PORT will not OPEN

2020-05-13 Thread Carmen Vitullo
wow - ok that's something I'd never suspect 


Carmen Vitullo 

- Original Message -

From: "Steve Beaver"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 13, 2020 8:52:15 AM 
Subject: Re: zOSMF - The PORT will not OPEN 

How amount NONE 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Jousma, David 
Sent: Wednesday, May 13, 2020 8:46 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zOSMF - The PORT will not OPEN 

Steve, 

How many files do you see at /usr/lpp/zosmf/lib? On my system there are 47, 
including the file you are missing libIzuCommandJni.so 

 
_ 
Dave Jousma 
AVP | Manager, Systems Engineering 

Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, 
MI 49546 
616.653.8429 | fax: 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver 
Sent: Wednesday, May 13, 2020 9:41 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: zOSMF - The PORT will not OPEN 

**CAUTION EXTERNAL EMAIL** 

**DO NOT open attachments or click on links from unknown senders or 
unexpected emails** 

Has anyone seen this error before out of zOSMF. The PORT will not OPEN 



ÝERROR ¨ CWWKE0701E: bundle 
com.ibm.zoszmf.command.management:1.0.0.qualifier 
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4 
27) ¨ : The activate method has thrown an exception 
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so 
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at 
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425) 
at java.lang.System.load(System.java:552) 
at 
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat 
e(UserProductExtensionCommandHandler.java:141) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90 
) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl 
.java:55) 
at java.lang.reflect.Method.invoke(Method.java:508) 
at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod. 
java:242) 
at Ýinternal classes¨ 






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

**DO NOT open attachments or click on links from unknown senders or 
unexpected emails** 


This e-mail transmission contains information that is confidential and may 
be privileged. It is intended only for the addressee(s) named above. If 
you receive this e-mail in error, please do not read, copy or disseminate it 
in any manner. If you are not the intended recipient, any disclosure, 
copying, distribution or use of the contents of this information is 
prohibited. Please reply to the message immediately by informing the sender 
that the message was misdirected. After replying, please erase it from your 
computer system. Your assistance in correcting this error is appreciated. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@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: zOSMF - The PORT will not OPEN

2020-05-13 Thread Jousma, David
Well, there's the answer then.   You seemed to have accidentally damaged your 
SMPE managed filesystem.   You are likely to be chasing these kinds of problems 
on an ongoing basis.   If you have other systems that are copies and you *know* 
matches your SMPE environment, you could rebuild that entire filesystem.   
Thenmy suggestion is mount read only.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 9:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

How amount NONE

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, May 13, 2020 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

How many files do you see at /usr/lpp/zosmf/lib?  On my system there are 47, 
including the file you are missing  libIzuCommandJni.so


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Has anyone seen this error before out of zOSMF.  The PORT will not OPEN

 

ÝERROR   ¨ CWWKE0701E: bundle
com.ibm.zoszmf.command.management:1.0.0.qualifier
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
27) ¨ : The activate method has thrown an exception
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425)
at java.lang.System.load(System.java:552)
at
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat
e(UserProductExtensionCommandHandler.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.
java:242)
at Ýinternal classes¨






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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it in 
any manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. 

Re: zOSMF - The PORT will not OPEN

2020-05-13 Thread Carmen Vitullo
I've had a similar issue, did you by chance shutdown the server and immediately 
start it, possibly before it was completely shutdown? 
I reported this problem to IBM then to find it was a corrupted file, due to a 
bad shutdown or a cancel ,I cannot get to my old emails currently sorry. 


also found 


https://www.ibm.com/support/pages/how-can-i-fix-error-cwwke0701e-javalangillegalstateexception-configuration-pid-comibmwskernelmetatypehelperfileset13-was-deleted
 





Carmen Vitullo 

- Original Message -

From: "Steve Beaver"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 13, 2020 8:40:58 AM 
Subject: zOSMF - The PORT will not OPEN 

Has anyone seen this error before out of zOSMF. The PORT will not OPEN 



ÝERROR ¨ CWWKE0701E: bundle 
com.ibm.zoszmf.command.management:1.0.0.qualifier 
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4 
27) ¨ : The activate method has thrown an exception 
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so 
(EDC5205S DLL module not found. (errno2=0xC40B0025)) 
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425) 
at java.lang.System.load(System.java:552) 
at 
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat 
e(UserProductExtensionCommandHandler.java:141) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90 
) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl 
.java:55) 
at java.lang.reflect.Method.invoke(Method.java:508) 
at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod. 
java:242) 
at Ýinternal classes¨ 






-- 
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: zOSMF - The PORT will not OPEN

2020-05-13 Thread Steve Beaver
How amount NONE

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, May 13, 2020 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - The PORT will not OPEN

Steve,

How many files do you see at /usr/lpp/zosmf/lib?  On my system there are 47,
including the file you are missing  libIzuCommandJni.so


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, May 13, 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Has anyone seen this error before out of zOSMF.  The PORT will not OPEN

 

ÝERROR   ¨ CWWKE0701E: bundle
com.ibm.zoszmf.command.management:1.0.0.qualifier
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
27) ¨ : The activate method has thrown an exception
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425)
at java.lang.System.load(System.java:552)
at
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat
e(UserProductExtensionCommandHandler.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.
java:242)
at Ýinternal classes¨






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

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@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: zOSMF - The PORT will not OPEN

2020-05-13 Thread Jousma, David
Steve,

How many files do you see at /usr/lpp/zosmf/lib?  On my system there are 47, 
including the file you are missing  libIzuCommandJni.so

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, May 13, 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - The PORT will not OPEN

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Has anyone seen this error before out of zOSMF.  The PORT will not OPEN

 

ÝERROR   ¨ CWWKE0701E: bundle
com.ibm.zoszmf.command.management:1.0.0.qualifier
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
27) ¨ : The activate method has thrown an exception
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
(EDC5205S DLL module not found. (errno2=0xC40B0025)) at 
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425)
at java.lang.System.load(System.java:552)
at
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat
e(UserProductExtensionCommandHandler.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.
java:242)
at Ýinternal classes¨






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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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


zOSMF - The PORT will not OPEN

2020-05-13 Thread Steve Beaver
Has anyone seen this error before out of zOSMF.  The PORT will not OPEN

 

ÝERROR   ¨ CWWKE0701E: bundle
com.ibm.zoszmf.command.management:1.0.0.qualifier
(166)Ýcom.ibm.zoszmf.command.management.UserProductExtensionCommandHandler(4
27) ¨ : The activate method has thrown an exception
java.lang.UnsatisfiedLinkError: /usr/lpp/zosmf/lib/libIzuCommandJni.so
(EDC5205S DLL module not found. (errno2=0xC40B0025))
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1425)
at java.lang.System.load(System.java:552)
at
com.ibm.zoszmf.command.management.UserProductExtensionCommandHandler.activat
e(UserProductExtensionCommandHandler.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.
java:242)
at Ýinternal classes¨






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


Re: OA58438: ESQA SPIKE FAST RPB GROWTH SVCDUMP PROCESSING SP245 K0

2020-05-13 Thread Carmen Vitullo
luckily I have this applied :) 


Carmen Vitullo 

- Original Message -

From: "Lizette Koehler"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 13, 2020 8:15:49 AM 
Subject: OA58438: ESQA SPIKE FAST RPB GROWTH SVCDUMP PROCESSING SP245 K0 

A friend pointed this out from Feb 2020 - apparently unexpected IPL can 
occur before putting this on. 





https://www.ibm.com/support/pages/apar/OA58438 



At z/OS 2.3, RSM processing during SVCDUMP capture changed that 

causes an excessive amount of RPB Pools to be obtained in 

Subpool 245 Key 0 ESQA/SQA storage. These pools are x'2000' 

bytes each. 



In the case where this was diagnosed there were several thousand 
RPB Pools obtained in less than a second. 





Lizette 




-- 
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: OA58438: ESQA SPIKE FAST RPB GROWTH SVCDUMP PROCESSING SP245 K0

2020-05-13 Thread Carmen Vitullo
Thank you Lizette 


Carmen Vitullo 

- Original Message -

From: "Lizette Koehler"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, May 13, 2020 8:15:49 AM 
Subject: OA58438: ESQA SPIKE FAST RPB GROWTH SVCDUMP PROCESSING SP245 K0 

A friend pointed this out from Feb 2020 - apparently unexpected IPL can 
occur before putting this on. 





https://www.ibm.com/support/pages/apar/OA58438 



At z/OS 2.3, RSM processing during SVCDUMP capture changed that 

causes an excessive amount of RPB Pools to be obtained in 

Subpool 245 Key 0 ESQA/SQA storage. These pools are x'2000' 

bytes each. 



In the case where this was diagnosed there were several thousand 
RPB Pools obtained in less than a second. 





Lizette 




-- 
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: OA58438: ESQA SPIKE FAST RPB GROWTH SVCDUMP PROCESSING SP245 K0

2020-05-13 Thread Jousma, David
Thanks Lizette.  This applies to V2.4 as well for anyone wondering.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lizette Koehler
Sent: Wednesday, May 13, 2020 9:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: OA58438: ESQA SPIKE FAST RPB GROWTH SVCDUMP PROCESSING SP245 K0

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

A friend pointed this out from Feb 2020 - apparently unexpected IPL can occur 
before putting this on.

 

 

https://www.ibm.com/support/pages/apar/OA58438

 

At z/OS 2.3, RSM processing during SVCDUMP capture changed that

causes an excessive amount of RPB Pools to be obtained in

Subpool 245 Key 0 ESQA/SQA storage.  These pools are x'2000'

bytes each.  

 

In the case where this was diagnosed there were several thousand RPB Pools 
obtained in less than a second.

 

 

Lizette

 


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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


OA58438: ESQA SPIKE FAST RPB GROWTH SVCDUMP PROCESSING SP245 K0

2020-05-13 Thread Lizette Koehler
A friend pointed this out from Feb 2020 - apparently unexpected IPL can
occur before putting this on.

 

 

https://www.ibm.com/support/pages/apar/OA58438

 

At z/OS 2.3, RSM processing during SVCDUMP capture changed that

causes an excessive amount of RPB Pools to be obtained in

Subpool 245 Key 0 ESQA/SQA storage.  These pools are x'2000'

bytes each.  

 

In the case where this was diagnosed there were several thousand
RPB Pools obtained in less than a second.

 

 

Lizette

 


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


Re: WannaCry hero faces jail time

2020-05-13 Thread scott Ford
 Mike,

Thanks for the great article, I literally just read all of it. Amazing
story, he was a savant of sorts. I am not one to judge, right and wrong per
se have shades of gray.

Scott

On Wed, May 13, 2020 at 6:38 AM Seymour J Metz  wrote:

> I think that he should have gotten jail time, but I also think that his
> confession should have been thrown out and the FBI agents disciplined for
> failing to present the warrant at the time of his arrest, for failing to
> read him his Miranda rights and for interrogating him without a lawyer
> present.
>
> I also think that Wired should hire a proofreader with a technical
> background: the Web is not the Internet, among other things they got wrong.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Mike Schwab [mike.a.sch...@gmail.com]
> Sent: Wednesday, May 13, 2020 2:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: WannaCry hero faces jail time
>
>
> https://secure-web.cisco.com/1Fsb88pR44w_Yq0lMY7lOmuXWSr1sxFRT1sm43wEOkk8kyyivBZwqdHzu8GojIxaD9QzZIrj1k8EHc4pubOKw4355ZJ2NQVvk2pXjOZc8MizG4m1BmvOywRD-J0yqjqR0JJM3NO4cerGHFz4mrxFR7lSenSmr4Nsv4oj62TSXc3kK5jHEJYZWXV4b5RH1nBVQwLEUIvIuDxAKFj4tAlGme0fdu9gidT2BnwpCTfewAi1ey4cp7mRJb_Ufqeqp5LUtvpM2V1m1T7i6CsEEQvfVQ_mivfP1wImmgjvv7HrEKdNq5uetBv2oa4_RCnJiiju-U45oBO8gZIKO-M8ojuSg7IZ1tEE9iMtBIvaAdgtNFq_PfaMfv9ihFjJ_Bkir1TkrTnKAUkMT5zsw4r0eypHdjzL6Blzd8WrgGgr2VXd0CXzpX_7OIDpU-5kfJV4GuneoiPsCGyGciBS8QBHRZGqvoFsycWc0k6RXrzygc8Mkszo/https%3A%2F%2Fwww.wired.com%2Fstory%2Fconfessions-marcus-hutchins-hacker-who-saved-the-internet%2F%3Fmbid%3Dsocial_facebook%26utm_brand%3Dwired%26utm_medium%3Dsocial%26utm_social-type%3Downed%26utm_source%3Dfacebook
>
> --
> 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
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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


Re: TMSINIT

2020-05-13 Thread Nai, Dean
Thanks everyone for all the help.

.








On 5/13/20, 12:19 AM, "IBM Mainframe Discussion List on behalf of Russell Witt" 
 wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>Not exactly. The SECWTO does control if the WTOR asking for the userid and
>password of the user running TMSINIT as a started task is issued or not.
>However, you can change the option at any time. The "trick" is that if you
>change the option; it does not take effect until AFTER you have successfully
>executed TMSINIT to reset the option. So, you cannot just change the option
>and then run TMSINIT without the WTOR being issued. It will be the next time
>after before it takes effect.
>
>Now, one simple method for bypassing the WTOR is to not run TMSINIT as a
>started task. If it is run as a batch job (or even from TSO if you allocate
>the necessary files) you will not be prompted for the userid/password of the
>user running TMSINIT. And it is NOT the user-id of TMSINIT itself; it is
>simply the user-id of the person that entered the "S TMSINIT" operator
>command. In other words, WHO is running TMSINIT as a started task. 
>If the SECWTO option is set to NO, we won't ask and will simply allow anyone
>to run TMSINIT at any time (not exactly a secure way of running, but that is
>an option).
>
>Russell Witt
>CA 1 Architect
>Broadcom
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Nai, Dean
>Sent: Tuesday, May 12, 2020 1:25 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: TMSINIT
>
>If I remember correctly if SECTWO is set to yes at IPL then it remembers it
>until the next IPL and if you change it to no it won't work until the next
>IPL.
>
>Thanks:)
>
>
>
>From: IBM Mainframe Discussion List  on behalf of
>Carmen Vitullo 
>Sent: Tuesday, May 12, 2020 1:39 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: TMSINIT
>
>EXTERNAL:  Do not open attachments or click on links unless you recognize
>and trust the sender.
>
>IIRC it's the password used when you installed CA-1, one of the usermods,
>some sites use the default.
>it should be in a usermod or sampjcl member
>
>
>Carmen Vitullo
>
>- Original Message -
>
>From: "Dean Nai" 
>To: IBM-MAIN@LISTSERV.UA.EDU
>Sent: Tuesday, May 12, 2020 12:30:23 PM
>Subject: TMSINIT
>
>I know this isn't a Z question but people on here have knowledge about most
>things.
>
>
>I'm trying to run a CA-1 TMSINIT outside of an IPL and I'm getting this
>message. Nobody here knows what to reply. Any thoughts.
>
>
>IEFTMS32 - ENTER USERID AUTHORIZED TO RUN TMSINIT
>
>--
>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

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


Re: 3270 terminals: CUT vs. DFT

2020-05-13 Thread Ron Wells
I honestly can't imagine anyone wanting to reuse it-and the fact that nobody 
ever has might be seen as supporting that position.

??? make a bet.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Tuesday, May 12, 2020 6:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 3270 terminals: CUT vs. DFT

** EXTERNAL EMAIL - USE CAUTION **


Martin Packer wrote:

>It's such a nice efficient data stream that one might like to use it
>from

>other platforms.



"Efficient" how? Bandwidth? That's cheap now. 3270 data streams were fun 
because they were so complex. But expensive to program and use. And the fact 
that attribute bytes occupy space on the screen is really irritating when 
trying to design screens.



I honestly can't imagine anyone wanting to reuse it-and the fact that nobody 
ever has might be seen as supporting that position.



But each to his own!


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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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


Re: WannaCry hero faces jail time

2020-05-13 Thread Seymour J Metz
I think that he should have gotten jail time, but I also think that his 
confession should have been thrown out and the FBI agents disciplined for 
failing to present the warrant at the time of his arrest, for failing to read 
him his Miranda rights and for interrogating him without a lawyer present.

I also think that Wired should hire a proofreader with a technical background: 
the Web is not the Internet, among other things they got wrong.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Wednesday, May 13, 2020 2:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: WannaCry hero faces jail time

https://secure-web.cisco.com/1Fsb88pR44w_Yq0lMY7lOmuXWSr1sxFRT1sm43wEOkk8kyyivBZwqdHzu8GojIxaD9QzZIrj1k8EHc4pubOKw4355ZJ2NQVvk2pXjOZc8MizG4m1BmvOywRD-J0yqjqR0JJM3NO4cerGHFz4mrxFR7lSenSmr4Nsv4oj62TSXc3kK5jHEJYZWXV4b5RH1nBVQwLEUIvIuDxAKFj4tAlGme0fdu9gidT2BnwpCTfewAi1ey4cp7mRJb_Ufqeqp5LUtvpM2V1m1T7i6CsEEQvfVQ_mivfP1wImmgjvv7HrEKdNq5uetBv2oa4_RCnJiiju-U45oBO8gZIKO-M8ojuSg7IZ1tEE9iMtBIvaAdgtNFq_PfaMfv9ihFjJ_Bkir1TkrTnKAUkMT5zsw4r0eypHdjzL6Blzd8WrgGgr2VXd0CXzpX_7OIDpU-5kfJV4GuneoiPsCGyGciBS8QBHRZGqvoFsycWc0k6RXrzygc8Mkszo/https%3A%2F%2Fwww.wired.com%2Fstory%2Fconfessions-marcus-hutchins-hacker-who-saved-the-internet%2F%3Fmbid%3Dsocial_facebook%26utm_brand%3Dwired%26utm_medium%3Dsocial%26utm_social-type%3Downed%26utm_source%3Dfacebook

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

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


WannaCry hero faces jail time

2020-05-13 Thread Mike Schwab
https://www.wired.com/story/confessions-marcus-hutchins-hacker-who-saved-the-internet/?mbid=social_facebook_brand=wired_medium=social_social-type=owned_source=facebook

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