Re: empty KSDS behavior - why?

2018-05-27 Thread Paul Gilmartin 
On Sun, 27 May 2018 22:46:52 -0500, Edward Gould wrote:

>> On May 27, 2018, at 8:51 PM, Charles Mills wrote:
>> 
>> Exactly. I am no VSAM guy ... but whatever magic you have to do manually go 
>> get the VSAM file to be readable, why can't AMS just do that when it creates 
>> the file? Is there any reason anyone would want a "virginal" (unreadable) 
>> VSAM file specifically?
>> 
>> How many ABENDs, how many application problems, how many stupid little 
>> customer fixup programs and PROCs could have been saved if AMS just did that 
>> from the get-go?
>> 
>> Or am I missing something? As I say, I am no VSAM guy.
>> 
>I like many others feel your pain. I can understand it in a way, say a KSDS 
>and (in your world) VSAM automagically adds a record. What key would IBM 
>possibly use that high end up without it being a duplicate key. RRDS would 
>automatically loose 1 record as the first record would be ??. IBM decided (I 
>think) to take it as its *YOUR* dataset and its up to you to prime it.
>
No, no!  The suggestion was that it should automagically add one record, 
*then*delete*it*.
(Others have said this suffices.)  Or, in a shortcut initialize the data set in 
such a state.
Once the record is gone, it doesn't matter what the key was.  There's nothing 
for any record
subsequently inserted to be a duplicate key of.

(But does that create a CA/CI for a range that the customer would never use and
leave it dangling?)

What happens when the programmer REPROs an empty KSDS which formerly contained
records in order to reorganize it and prune otiose CA/CIs?

(I recall a time when HSM considered it an error to migrate a PDS with no 
members.)

-- gil

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

Re: empty KSDS behavior - why?

2018-05-27 Thread Edward Gould 
> On May 27, 2018, at 8:51 PM, Charles Mills  wrote:
> 
> Exactly. I am no VSAM guy ... but whatever magic you have to do manually go 
> get the VSAM file to be readable, why can't AMS just do that when it creates 
> the file? Is there any reason anyone would want a "virginal" (unreadable) 
> VSAM file specifically?
> 
> How many ABENDs, how many application problems, how many stupid little 
> customer fixup programs and PROCs could have been saved if AMS just did that 
> from the get-go?
> 
> Or am I missing something? As I say, I am no VSAM guy.
> 
> Charles
Charles,
I like many others feel your pain. I can understand it in a way, say a KSDS and 
(in your world) VSAM automagically adds a record. What key would IBM possibly 
use that high end up without it being a duplicate key. RRDS would automatically 
loose 1 record as the first record would be ??. IBM decided (I think) to take 
it as its *YOUR* dataset and its up to you to prime it.
Ed


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

Re: empty KSDS behavior - why?

2018-05-27 Thread Charles Mills 
Exactly. I am no VSAM guy ... but whatever magic you have to do manually go get 
the VSAM file to be readable, why can't AMS just do that when it creates the 
file? Is there any reason anyone would want a "virginal" (unreadable) VSAM file 
specifically?

How many ABENDs, how many application problems, how many stupid little customer 
fixup programs and PROCs could have been saved if AMS just did that from the 
get-go?

Or am I missing something? As I say, I am no VSAM guy.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Sunday, May 27, 2018 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Not really. It's more like making you create a VTOC after you've formated the 
drive instead of making the creation of the VTOC part of the formatting. 
Pre-SMS there was a similar problem with sequential DASD files; you had to open 
them for output if you wanted to use them as empty input files.

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

Fwd: NAB mainframe turns its TOESUP* after power outage, offline 7 hours • The Register

2018-05-27 Thread Mark Regan 
 National Australia Bank

https://www.theregister.co.uk/2018/05/27/nab_mainframe_outage/

Not a mainframe problem, but one with the data center's electrical power
infrastructure.

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

Re: empty KSDS behavior - why?

2018-05-27 Thread Seymour J Metz 
Not really. It's more like making you create a VTOC after you've formated the 
drive instead of making the creation of the VTOC part of the formatting. 
Pre-SMS there was a similar problem with sequential DASD files; you had to open 
them for output if you wanted to use them as empty input files.


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


From: IBM Mainframe Discussion List  on behalf of Ron 
hawkins 
Sent: Sunday, May 27, 2018 3:24 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: empty KSDS behavior - why?

I think it's more like "why do we have to format disk drives."

Even a VTOC needs to know where things start and end.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Saturday, May 26, 2018 2:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] empty KSDS behavior - why?

W dniu 2018-05-26 o 02:47, Paul Gilmartin pisze:
> On Sat, 26 May 2018 00:20:34 +, Frank Swarbrick wrote:
>
>> Pointless issue of the day.  This has bothered me for 20 years.  I figured 
>> its about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never 
>> been "loaded") have what seems to be to be a "special" behavior, one that is 
>> different than a KSDS that had records but no longer has any (all records 
>> have been deleted).
>>
> I suppose it's like formatting a disk: no VTOC is different from an empty 
> VTOC.
> But, yes, Why‽  Why does SMP/E require me to REPRO GIMZPOOL?  Why
> isn't this embedded in DEFINE CLUSTER?

Yes, it is like disk ad VTOC, but it *shouldn't* be like.
Indeed empty VSAM file is not the same as ever user VSAM file. It complicates 
VSAM processing in application, or to simplfy, many applications do require to 
"seed" the cluster with some dummy record before use.
Can it be changed? Well, can we relieve JCL syntax? ;-)

--
Radoslaw Skorupka
Lodz, Poland




==


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

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

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
http://secure-web.cisco.com/14WcenTauxUxkOdC529500dhYAnBt6pGtc3wdjkfqe5twVmP4G1yNK-GkHNROQRq201tTX8tGqLTg_EN7GydcDoqoK6_gLjbYld7d8-8Hv1099w4wnf3rIdGdr8XcdtQ61c9szzjm1cGxPgQWJ7slUes337UaAO5gr1b6KT7_SolB9eiO9l_KWiQ2fHvYw4CT9StnVW8xhMgUwCYsWCin2_g5UDh4v5kKxPNf1l9JvZO5qe5W26oiI_kaVeq_Im8GfrCyLy37_jnGeAdW9qKxGg3Ga67ljxp3MgKf-QchVJz8WketdCXihmPJIF6gC3BD0M053SKxvXzZgU1sBEy5H7CUKq2zVqW4q40qd0glBa2vxGr553dxQoGyivGImKUb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 
025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


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

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


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

Re: empty KSDS behavior - why?

2018-05-27 Thread Ron hawkins 
I think it's more like "why do we have to format disk drives."

Even a VTOC needs to know where things start and end.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Saturday, May 26, 2018 2:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] empty KSDS behavior - why?

W dniu 2018-05-26 o 02:47, Paul Gilmartin pisze:
> On Sat, 26 May 2018 00:20:34 +, Frank Swarbrick wrote:
>
>> Pointless issue of the day.  This has bothered me for 20 years.  I figured 
>> its about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never 
>> been "loaded") have what seems to be to be a "special" behavior, one that is 
>> different than a KSDS that had records but no longer has any (all records 
>> have been deleted).
>>
> I suppose it's like formatting a disk: no VTOC is different from an empty 
> VTOC.
> But, yes, Why‽  Why does SMP/E require me to REPRO GIMZPOOL?  Why 
> isn't this embedded in DEFINE CLUSTER?

Yes, it is like disk ad VTOC, but it *shouldn't* be like.
Indeed empty VSAM file is not the same as ever user VSAM file. It complicates 
VSAM processing in application, or to simplfy, many applications do require to 
"seed" the cluster with some dummy record before use.
Can it be changed? Well, can we relieve JCL syntax? ;-)

--
Radoslaw Skorupka
Lodz, Poland




==


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

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

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


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

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

Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?

2018-05-27 Thread Jesse 1 Robinson 
Around 1980 when I first got into Systems, I was given an assembler program 
that processed SMF data. One particular record type had changed recently: the 
offset of some data of interest had shifted. The previous program owner had 
chosen to accommodate this change by checking some upfront flag to determine 
format. If new format, alter some MVC instructions accordingly (!), otherwise 
run as originally written. I was scandalized. It worked but violated most every 
principle I had adopted as an application programmer. My first action was to 
impose civility on the program. Sheesh.   

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Sunday, May 27, 2018 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: How to get BPX loadhfs (BPX1LOD) to load module into 
writable memory?

There's the definition of reentrant and then there's the handling of the RENT 
option in various contexts. Don't expect the Binder to be consistent with the 
Linkage Editor, or that the behavior of load modules, program objects and Unix 
files will be consistent. But it would be nice if IBM ever disentangled the 
mess.

BTW, I consider it bad form for code to modify itself, even if it is in fact 
reentrant or refreshable.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, May 25, 2018 7:49 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: How to get BPX loadhfs (BPX1LOD) to load module into writable 
memory?

On Fri, 25 May 2018 22:23:09 +0200, Peter Hunkeler wrote:

>>> What was Peter H. (informally?) quoting without citation?
> >
>>In: z/OS  IBM MVS Program Management: User's Guide and Reference 
>>Version 2 Release 3  SA23-1393-30
>
>Re-read my post and you will find my citation. I admit I missed the word 
>"Reference" and I did not include the pubs number. I thought it would be 
>understood, nevertheless. It seems, not. I'm sorry for the confusion this may 
>have caused.
>
OK.  You posted from "Glossary" (which I hadn't noticed):
reenterable
The reusability attribute that allows a program to be used concurrently by 
more
than one task. A reenterable module can modify its own data or other shared
resources, if appropriate serialization is in place to prevent interference 
between
using tasks. See reusability.
>
That's how I recall the behavior from decades ago.  But it appears to be 
contradicted, at least in spirit, by the "options reference":

On Fri, 25 May 2018 13:23:58 -0500, Paul Gilmartin wrote:

>On Tue, 22 May 2018 15:27:32 -0400, Thomas David Rivers wrote:
>
>>The BPX loadhfs function (BPX1LOD) loads an HFS executable into 
>>memory.
>>
>>It seems, that sometimes, this is loaded into writable memory and 
>>sometimes into read-only memory.
>>
>>There doesn't seem to be a way to indicate which is desired.. is there 
>>some OS-interface that writable memory be used?
>>
>What was Peter H. (informally?) quoting without citation?
>
>In: z/OS  IBM MVS Program Management: User's Guide and Reference 
>Version 2 Release 3  SA23-1393-30
>
>Chapter 6. Binder options reference
>Binder options
>REUS: Reusability options`
>RENT
>The module is reenterable. It can be executed by more than one
>task at a time. A task can begin executing it before a previous
>task has completed execution. A reenterable module is ordinarily
>expected not to modify its own code. In some cases, MVS protects
>the reentrant module's virtual storage so that it cannot be
>modified except by a program running in key 0. These cases
>include programs which the system treats as having been loaded
>from an authorized library, and also programs running under UNIX
>unless a debugging environment has been specified.
>
>Reenterable modules are also serially reusable.
>
>So, WAD.
>
>I dislike some things about this:
>
>o "include" is undesirably vague.  The Ref. should specify exactly
>  the cases in which ... programs are [so] treated.  A precise "are"
>  is preferable to the imprecise "include".  What other cases may
>  there be?  "[T]reats as having been ..." is likewise vague.  Provide
>  at least a citation of an explanation of what this means.
>
>o Simpler Is Better.  I see no good reason to treat "programs running
>  under UNIX" differently from other programs.
>
>o "ordinarily expected".  Is this a retreat from the earlier well-known
>  rule (cited by Peter) that a RENT program was allowed to modify its
>  own code given proper serialization?

-- gil


--
For IBM-MAIN

Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?

2018-05-27 Thread Seymour J Metz 
There's the definition of reentrant and then there's the handling of the RENT 
option in various contexts. Don't expect the Binder to be consistent with the 
Linkage Editor, or that the behavior of load modules, program objects and Unix 
files will be consistent. But it would be nice if IBM ever disentangled the 
mess.

BTW, I consider it bad form for code to modify itself, even if it is in fact 
reentrant or refreshable.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, May 25, 2018 7:49 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: How to get BPX loadhfs (BPX1LOD) to load module into writable 
memory?

On Fri, 25 May 2018 22:23:09 +0200, Peter Hunkeler wrote:

>>> What was Peter H. (informally?) quoting without citation?
> >
>>In: z/OS  IBM MVS Program Management: User's Guide and Reference
>>Version 2 Release 3  SA23-1393-30
>
>Re-read my post and you will find my citation. I admit I missed the word 
>"Reference" and I did not include the pubs number. I thought it would be 
>understood, nevertheless. It seems, not. I'm sorry for the confusion this may 
>have caused.
>
OK.  You posted from "Glossary" (which I hadn't noticed):
reenterable
The reusability attribute that allows a program to be used concurrently by 
more
than one task. A reenterable module can modify its own data or other shared
resources, if appropriate serialization is in place to prevent interference 
between
using tasks. See reusability.
>
That's how I recall the behavior from decades ago.  But it appears to be 
contradicted,
at least in spirit, by the "options reference":

On Fri, 25 May 2018 13:23:58 -0500, Paul Gilmartin wrote:

>On Tue, 22 May 2018 15:27:32 -0400, Thomas David Rivers wrote:
>
>>The BPX loadhfs function (BPX1LOD) loads an HFS executable
>>into memory.
>>
>>It seems, that sometimes, this is loaded into writable memory
>>and sometimes into read-only memory.
>>
>>There doesn't seem to be a way to indicate which is desired.. is there
>>some OS-interface that writable memory be used?
>>
>What was Peter H. (informally?) quoting without citation?
>
>In: z/OS  IBM MVS Program Management: User's Guide and Reference
>Version 2 Release 3  SA23-1393-30
>
>Chapter 6. Binder options reference
>Binder options
>REUS: Reusability options`
>RENT
>The module is reenterable. It can be executed by more than one
>task at a time. A task can begin executing it before a previous
>task has completed execution. A reenterable module is ordinarily
>expected not to modify its own code. In some cases, MVS protects
>the reentrant module's virtual storage so that it cannot be
>modified except by a program running in key 0. These cases
>include programs which the system treats as having been loaded
>from an authorized library, and also programs running under UNIX
>unless a debugging environment has been specified.
>
>Reenterable modules are also serially reusable.
>
>So, WAD.
>
>I dislike some things about this:
>
>o "include" is undesirably vague.  The Ref. should specify exactly
>  the cases in which ... programs are [so] treated.  A precise "are"
>  is preferable to the imprecise "include".  What other cases may
>  there be?  "[T]reats as having been ..." is likewise vague.  Provide
>  at least a citation of an explanation of what this means.
>
>o Simpler Is Better.  I see no good reason to treat "programs running
>  under UNIX" differently from other programs.
>
>o "ordinarily expected".  Is this a retreat from the earlier well-known
>  rule (cited by Peter) that a RENT program was allowed to modify its
>  own code given proper serialization?

-- gil

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

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

Re: empty KSDS behavior - why?

2018-05-27 Thread Seymour J Metz 
I've considered it a minor nuisance since day one. I got used to it, but never 
learned to like it.


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


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Friday, May 25, 2018 8:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: empty KSDS behavior - why?

Pointless issue of the day.  This has bothered me for 20 years.  I figured its 
about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never been 
"loaded") have what seems to be to be a "special" behavior, one that is 
different than a KSDS that had records but no longer has any (all records have 
been deleted).

For example, if a file in this "never loaded" state is opened for input by 
IDCAMS you get this:

 PRINT INFILE(CCMIGR)
IDC3300I  ERROR OPENING DVFJS.CCARD.CCMIGRX
IDC3351I ** VSAM OPEN RETURN CODE IS 160
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0

where
160
The operands specified in the ACB or GENCB macro are
inconsistent with each other or with the information in the
catalog record. This error can also occur when the VSAM
cluster being opened is empty.

If opened by SORT (DFSORT)
IEC161I 
072-053,DEFVSAM,PRINT1,CCMIGR,,,DVFJS.CCARD.CCMIGRX,DVFJS.CCARD.CCMIGRX.DATA,CATALOG.USERCAT.PPCAT

where
IEC161I (072)

  Specific information for this return code: The data set was empty, but the 
ACB (access method control block) for the data set indicated that it was being 
opened for input only.

System action

  OPEN processing ends for the data set. The error flag (ACBERFLG) in the ACB 
(access method block) for the data set is set to 160 (X'A0').


When opened by a COBOL program, you get file status 35 (An OPEN statement with 
the INPUT, I-O, or EXTEND phrase was attempted on a non-optional file that was 
unavailable.), unless you declare it as OPTIONAL, in which case you get file 
status 05 (An OPEN statement was successfully executed, but the referenced 
optional file was unavailable at the time the OPEN statement was executed. The 
file had been created if the open mode was I-O or EXTEND.)

Is this "feature" supposed to be helpful in some obscure edge case?  Or is it 
simply always annoying?

The OPTIONAL solution in COBOL is generally how we get around this issue, 
rather than loading a dummy record or something.  But why?  Why, why, why does 
this behavior even exist?

Frank


--
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: smp/e question - PTF relinks, but missing CSECTs.

2018-05-27 Thread Seymour J Metz 
I would probably have called his boss and recorded it, then let my boss here 
the recording. But all's well that end's well. 


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


From: IBM Mainframe Discussion List  on behalf of 
Edward Gould 
Sent: Friday, May 25, 2018 8:38 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: smp/e question - PTF relinks, but missing CSECTs.

> On May 25, 2018, at 12:39 PM, Jesse 1 Robinson  
> wrote:
>
> I'm sympathetic to the argument that new stuff should be investigated, but 
> the problem is whether that really happens in practice. We've all met the 
> sysprog who meticulously codes parameter defaults as a kind of in-your-face 
> documentation so that 'we will all know' what's happening. Then years later 
> the defaults change, but the user-coded list does not get updated. Call me 
> Pollyanna, but I'm willing to trust the latest default.
>
> As for getting inconsistent results, I suspect that SMP/E results can be 
> influenced by the particular mix of elements being processed in a given run. 
> That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover a 
> sinkhole that applying one sysmod or the other alone would not. This problem 
> is very difficult to detect in development and may require a lot of customer 
> activity to unearth.
>
> .
Jess1,
*YEARS* ago with a well known vendor I was trying to apply a zap (gotten in 
Hardcopy from the vendor) the module was right but the csect did not exist in 
the module flushed the zap, I called the vendor and the person I talked to 
started to argue with me about how I coded the zap. I was annoyed and said fine 
I will fax you the output. I faxed him the sheet of paper.. I did not hear back 
from him in an hour so I called him. He said I had coded the zap wrong, I 
looked at the zap again because I do not miscode zaps. I did this on the phone 
with him. I said the first column is blank and then the word "name” and then 
there is the module name and a blank and the csect name,  the rest of the card 
out to 72 is blank. What is wrong with it? He said you must be a beginner you 
never code zap statements like that. I said EXCUSE me that is how a the first 
zap statement is coded, I do this daily with another vendor and that is by the 
book how its done.  He told me I was wrong and not to bother him again. I said 
what? He hung the phone up on me. I went to the boss and explained to him what 
had transpired and he took a look at my zap statements and he said OK we will 
get him on the line. The guy hung up the phone and soon as he heard the 
company. My boss called the marketing rep and explained what was going on, the 
marketing rep followed the top-down chart as to who the guys boss was. 5 
minutes later we get a call from the guys boss and explains that the guy had a 
bad day. We explained the situation and he said what you are telling me you are 
correct, let me check with another technician he puts us on hold (with lousy 
music on top of it). The technician gets back on the the phone and said there 
was a typo on the sheet and its being faxed to all the customers as we speak. I 
said OK, but the treatment I got from this other technician was just wrong and 
a customer should never be treated that way. He said he will take it up with 
his management. My boss was surprised at me speaking up like I did, but I was 
pissed. The next day I called in with a small question on a wording of a zap 
and what sequence it was supposed to go on. A technician got on and I asked the 
question and he said he was happy we had caught the issue. I said OK thank you. 
He said was I going to report him? I said no why should I, you handled the call 
correctly. He said the technician I had talked to yesterday was fired.



> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com 

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

2018-05-27 Thread Edward Gould 
> On May 24, 2018, at 8:49 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Thu, 24 May 2018 20:03:55 -0500, Edward Gould wrote:
>> 
>> Our big boss was trying to show the board how he tried to save money. They 
>> sort of forced him into getting STC (now STK) tape drives. All of a sudden 
>> some of our jobs were getting S237 (block count did not match trailers), STC 
>> said we had bum tapes, we went through all sort of shenanigans to prove they 
>> weren’t. I had to write a program that counted blocks and compare it the 
>> tapes count. The entire mess ended up with STC getting kicked out and IBM 
>> drives were brought back in. Of course never a S237 with a IBM drive. Our 
>> tape library while not super large it was large and finally management 
>> finally figured it out in order to get good people you had to hire/pay for 
>> them. 
>> 
> You couldn't just discard the tape if the data were precious.
Of course not they at least checked in TMS to see.
> 
> Just curious: did it write blocks and not count them or count blocks and not 
> write them?
> (Full disclosure: I may have been a StorageTek (AKA STC, AKA STK) employee 
> around
> that time.)
It seemed *NOT* to write the block. and that is what scared us the most how 
much data did we loose. I wasn’t privy into the investigation (but I guess it 
caused quite a uproar in upper echelons) People were assigned to find out how 
much data was lost. We did not work with any money it was just data to us. 
Luckily (I guess) none of the tapes contained any master data (we had a huge 
database of everybody in the country that subscribed to our magazines and 
books, records(CD'sl), etc . This was “our treasure”. This was 30++ years ago 
and I do not remember the Number of tapes (6250) that contained the maser file 
but it was probably in the 60’s.
> 
> I once read a tape, all CDC equipment; no IBM nor StorageTek and discovered
> an entire block missing with no error reported.  I visually inspected the 
> first few
> meters of the tape and noticed a transverse crease.  I assume that wafted
> exactly one block over the read heads.  Score -1 for NRZI.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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