DASD VOL1 label question

[Tony Thigpen]

I was playing with flash-copy and I came across something I have not 
seen before as it relates to the VOL1 label on some DASD and I can't 
find it documented anywhere.


At the very end of the VOL1 record, starting at offset x'48' (decimal 
position 73-80).

On pack 558, I am seeing "D84B EEEB0558 0559"
On pack 55F, I am seeing "D84B B20D055F 0558"

I am sure these areas are related to some flash copy testing I am doing 
as the last 4 bytes seem to be source-CCUU and dest-CCUU for some flash 
testing and I am seeing them on packs that are involved with flash-copy 
(both source and dest).


Does anybody know of any doc on these fields?


Tony Thigpen

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

EC6 ABEND with X'00FFCE54' in R15

[Thomas David Rivers]

I'm running a small program that uses BPX pthreads
along with CEEPIPI.

The program is a Systems/C program that uses BPX pthreads
to start up a HEAVY thread that then creates a CEEPIPI environment,
calls a simple IBM C (LE) function and returns, then destroys
the CEEPIPI environment and then the pthread ends with a pthread_exit().

Under BATCH, the program runs just fine.  


But - under TSO the program runs to completion and
then gets an ABEND and the message:


IEA848I NO DUMP WAS PRODUCED FOR THIS ABEND, DUE TO SYSTEM OR 
INSTALLATION REQUEST


Catching the ABEND with an ESPIE, I find that it is an
SEC6 ABEND, with R15 containing X'00FFCE54'.

Unfortunately the CE54 reason-code doesn't seem to be
documented for the EC6 ABEND.   And the EC6 documentation
says R15 may, or may-not contain a reason-code... so - can't
really tell.   And, since the dump is suppresed... I get no info,
and since the program runs fine under batch, I can't get a dump
there.

I would hazard a guess that something is amis with some callable
service somewhere... possibly BPX exit(),  but I'm hoping someone
might have run into that CE54 reason-code before?  I didn't find
any PTFs that mention it.

This is z/OS 2.4.

  - Thanks -
 - Dave Rivers -






--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)

[Jim Mulder]

https://www.cs.tufts.edu/comp/150FP/archive/alfred-spector/spector87ibm.pdf


Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY



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

Re: Two possibly related "historical" z/OS C library questions

[Charles Mills]

Okay, I managed to track down part of the answer. Almost fifteen years ago,
indeed! November, 2005. I was searching the archives of this list but it
turned out I had posted the question on MVS-OE. I only see part of the
thread, but it seems I ran into
https://www.ibm.com/support/pages/apar/II12870 and the answer was
BPX1SDD(1).

Based on the fact that the APAR was for OS/390 in 2001, and that it seems to
be working today without BPX1SDD(1), would you all think it was safe to
assume that the problem has gone away and I can drop the BPX1SDD() out of
the code?

That's really another way of phrasing question 2. below. Why would anyone
want to set the dub default, and what are the pros and cons of doing it one
way or another? (There are about eight or so different dub type settings.)
Where is that documented, or was there a SHARE presentation, or ... ?

I am still curious about question 1. but it is really a curiosity question.
I am now checking for either the string or a leading '/' and that seems to
be working.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, August 7, 2020 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Two possibly related "historical" z/OS C library questions

Fairly recent history: not drum memory or anything.

1. I have code written about fifteen years or so ago that contains comments
and code logic that indicates that for a FILE opened to a UNIX path fldata()
returns "...PATH=.SPECIFIED..." in __dsname. That is not true (any more?):
__dsname contains the actual UNIX file name and is so documented. Am I
confused? Or did it change? 

2. Based on finding that string in __dsname the code does a BPX1SDD (set dub
default) of 1. The comments indicate that otherwise a subsequent invocation
by the code of FTP will fail. But the logic stopped working at some point:
because there was no "...PATH=.SPECIFIED..." we have not been setting the
dub default, but it all still seems to be working, at least generally. Was
setting the dub default formerly necessary in some circumstances but no
longer necessary?

Is there any "why?" documentation for BPX1SDD()? It is decently documented
as to *what* it does, but is there any explanation anywhere of why one might
need to set the dub default, and what the pros and cons of the various
values might be?

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

Re: Why EZA1685W Invalid local file identifier ?

[Charles Mills]

I don't know. I don't know UNIX (z or otherwise) well enough to have a 
"feeling" for what is going on.

LCD '' fixes it, so my *guess* is that it just somehow has "UNIX paths on the 
brain" and //DD: looks wrong to it. That's my mental model. No real idea.

If it is not documented behavior I would say it feels like a bug to me, too.

Too bad I'm a red-headed stepchild (otherwise known as a Dallas customer) 
rather than a z/OS licensee, and therefore cannot open PMRs.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, August 7, 2020 3:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why EZA1685W Invalid local file identifier ?

On Fri, 7 Aug 2020 14:34:03 -0700, Charles Mills wrote:

>Solved. Is this documented FTP behavior? Looks like a bug to me. z/OS V2R2
>for what it's worth.
>
>Given //MYOUTPUT DD SYSOUT=*
>GET 'my.pds(member)' //DD:MYOUTPUT
>Succeeds as it should, but not if it is preceded by
>
>LCD /u/usr
>
>In which case you get the error message of the subject. Is that what people
>would expect? Is that documented?
>
>You can "fix" it by adding LCD '' between the two commands. In other words,
>GET to a DD fails if the current local directory is a UNIX path.
> 
Is it possible that when LCD is a UNIX path, GET forks a new address space
to facilitate resolution of relative paths, but this loses DDNAMEs?

Feels like a bug.

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

Re: Why EZA1685W Invalid local file identifier ?

[Paul Gilmartin]

On Fri, 7 Aug 2020 14:34:03 -0700, Charles Mills wrote:

>Solved. Is this documented FTP behavior? Looks like a bug to me. z/OS V2R2
>for what it's worth.
>
>Given //MYOUTPUT DD SYSOUT=*
>GET 'my.pds(member)' //DD:MYOUTPUT
>Succeeds as it should, but not if it is preceded by
>
>LCD /u/usr
>
>In which case you get the error message of the subject. Is that what people
>would expect? Is that documented?
>
>You can "fix" it by adding LCD '' between the two commands. In other words,
>GET to a DD fails if the current local directory is a UNIX path.
> 
Is it possible that when LCD is a UNIX path, GET forks a new address space
to facilitate resolution of relative paths, but this loses DDNAMEs?

Feels like a bug.

-- gil

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

Re: Why EZA1685W Invalid local file identifier ?

[Charles Mills]

> Doesn’t Filetype=JES try to get JES output from spool?

Basically yes. Local file name is still the local file name. The particular 
syntax shown submits 'legacy.dataset' as a job and retrieves the output into 
//DD: (when it's working!).

That part of the code is all working and has been working for years.

And thanks, but we crossed in the mail, I hacked at it until I found it. See my 
subsequent e-mail.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Michael Babcock
Sent: Friday, August 7, 2020 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why EZA1685W Invalid local file identifier ?

Doesn’t Filetype=JES try to get JES output from spool?

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

Re: OT: OOBOL and English was Re: Still COBOL After All These Years?

[Don Leahy]

Acronym War!


On Fri, Aug 7, 2020 at 06:53 Joe Monk  wrote:

> Not a good idea to be hurling insults from a work account.
>
> Joe
>
> On Fri, Aug 7, 2020 at 4:25 AM R.S. 
> wrote:
>
> > BBC
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> >
> >
> >
> >
> > W dniu 07.08.2020 o 03:28, Seymour J Metz pisze:
> > > PKB
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> > behalf of R.S. 
> > > Sent: Thursday, August 6, 2020 5:25 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: OT: OOBOL and English was Re: Still COBOL After All These
> > Years?
> > >
> > > W dniu 05.08.2020 o 17:07, Seymour J Metz pisze:
> > >> Must you be so obtuse? The structure that they devised is extremely
> > hard to change. Look at how long it took for everyone to switch from the
> > Julian Calendar to the Gregorian calendar.
> > >>
> > >> Yes, Europe has had treaties, and before the ones that you mentioned
> at
> > that, but some things are easier to change than others. Let me know when,
> > e.g., Europe gets rid of its royalty (yes, I know that they're mostly
> > symbolic.)
> > > Must you be so boorish?
> > > Must you insult people?
> > > Don't you have better hobby? This is not the place for your rudeness,
> > > better would be psychiatric office.
> > >
> > > --
> > > Radoslaw Skorupka
> > > Lodz, Poland
> > >
> >
> >
> >
> >
> > ==
> >
> > 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ść l
> ub
> 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, distribut
> es)
> 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
>

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

Re: Why EZA1685W Invalid local file identifier ?

[Charles Mills]

Solved. Is this documented FTP behavior? Looks like a bug to me. z/OS V2R2
for what it's worth.

Given //MYOUTPUT DD SYSOUT=*

GET 'my.pds(member)' //DD:MYOUTPUT 

Succeeds as it should, but not if it is preceded by 

LCD /u/usr

In which case you get the error message of the subject. Is that what people
would expect? Is that documented?

You can "fix" it by adding LCD '' between the two commands. In other words,
GET to a DD fails if the current local directory is a UNIX path. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, August 7, 2020 1:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Why EZA1685W Invalid local file identifier ?

I apologize: this is an incomplete question. It is impossible to post
"everything."

The question: I invoke FTP from a z/OS batch program. The indicated
statement fails as shown:

EZA1736I Quote Site   FileType=JES NoTrail

EZA1701I >>> Site   FileType=JES NoTrail

200 SITE command was accepted

EZA1460I Command:

EZA1736I Get 'valid.remote.traditional.dataset.name' //DD:SYS2   
EZA1685W Invalid local file identifier

EZA1735I Std Return Code = 16000, Error Code = 00018   

I looked at the listing in hex: there are no junk characters in there.
SYS2 is dynamically allocated to VIO. I am not in a position to prove
that the allocation is correct, but note that the error is on the "file
identifier" not on the file characteristics. SYS2 is definitely
allocated: I see IGD100I VIO ALLOCATED TO DDNAME SYS2 DATACLAS (
) in the system messages.

FWIW, the following works correctly earlier in the same FTP command stream,
so basic DD: is not the problem.

Put //DD:SYS1 'remote.dataset.name'

There are no intervening LOCSITE subcommands.
 
The problem seems to have something to do with the batch program's earlier
processing of z UNIX files. I don't have things diagnosed enough to say "it
fails if the program does X." It "used to work" so the problem is something
subtle.

I'm wondering if anyone has seen this before. Perhaps "oh yeah, you have to
Y if you do X, otherwise you get that." I have tried with and without
setting a DUB default of 1 before the FTP.

The GET subcommand frankly just outright seems correct on its face.

Thanks, and again, apologies that all of the *possibly* relevant detail is
way too voluminous to include. If anyone has a "what about X?" question I
will try to answer it.  

Charles 

--
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: Why EZA1685W Invalid local file identifier ?

[Michael Babcock]

Doesn’t Filetype=JES try to get JES output from spool?

On Fri, Aug 7, 2020 at 3:15 PM Charles Mills  wrote:

> I apologize: this is an incomplete question. It is impossible to post
> "everything."
>
> The question: I invoke FTP from a z/OS batch program. The indicated
> statement fails as shown:
>
> EZA1736I Quote Site   FileType=JES NoTrail
>
> EZA1701I >>> Site   FileType=JES NoTrail
>
> 200 SITE command was accepted
>
> EZA1460I Command:
>
> EZA1736I Get 'valid.remote.traditional.dataset.name' //DD:SYS2
> EZA1685W Invalid local file identifier
>
> EZA1735I Std Return Code = 16000, Error Code = 00018
>
> I looked at the listing in hex: there are no junk characters in there.
> SYS2 is dynamically allocated to VIO. I am not in a position to prove
> that the allocation is correct, but note that the error is on the "file
> identifier" not on the file characteristics. SYS2 is definitely
> allocated: I see IGD100I VIO ALLOCATED TO DDNAME SYS2 DATACLAS (
> ) in the system messages.
>
> FWIW, the following works correctly earlier in the same FTP command stream,
> so basic DD: is not the problem.
>
> Put //DD:SYS1 'remote.dataset.name'
>
> There are no intervening LOCSITE subcommands.
>
> The problem seems to have something to do with the batch program's earlier
> processing of z UNIX files. I don't have things diagnosed enough to say "it
> fails if the program does X." It "used to work" so the problem is something
> subtle.
>
> I'm wondering if anyone has seen this before. Perhaps "oh yeah, you have to
> Y if you do X, otherwise you get that." I have tried with and without
> setting a DUB default of 1 before the FTP.
>
> The GET subcommand frankly just outright seems correct on its face.
>
> Thanks, and again, apologies that all of the *possibly* relevant detail is
> way too voluminous to include. If anyone has a "what about X?" question I
> will try to answer it.
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Two possibly related "historical" z/OS C library questions

[Charles Mills]

Fairly recent history: not drum memory or anything.

1. I have code written about fifteen years or so ago that contains comments
and code logic that indicates that for a FILE opened to a UNIX path fldata()
returns "...PATH=.SPECIFIED..." in __dsname. That is not true (any more?):
__dsname contains the actual UNIX file name and is so documented. Am I
confused? Or did it change? 

2. Based on finding that string in __dsname the code does a BPX1SDD (set dub
default) of 1. The comments indicate that otherwise a subsequent invocation
by the code of FTP will fail. But the logic stopped working at some point:
because there was no "...PATH=.SPECIFIED..." we have not been setting the
dub default, but it all still seems to be working, at least generally. Was
setting the dub default formerly necessary in some circumstances but no
longer necessary?

Is there any "why?" documentation for BPX1SDD()? It is decently documented
as to *what* it does, but is there any explanation anywhere of why one might
need to set the dub default, and what the pros and cons of the various
values might be?

Thanks,
Charles

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

Why EZA1685W Invalid local file identifier ?

[Charles Mills]

I apologize: this is an incomplete question. It is impossible to post
"everything."

The question: I invoke FTP from a z/OS batch program. The indicated
statement fails as shown:

EZA1736I Quote Site   FileType=JES NoTrail

EZA1701I >>> Site   FileType=JES NoTrail

200 SITE command was accepted

EZA1460I Command:

EZA1736I Get 'valid.remote.traditional.dataset.name' //DD:SYS2   
EZA1685W Invalid local file identifier

EZA1735I Std Return Code = 16000, Error Code = 00018   

I looked at the listing in hex: there are no junk characters in there.
SYS2 is dynamically allocated to VIO. I am not in a position to prove
that the allocation is correct, but note that the error is on the "file
identifier" not on the file characteristics. SYS2 is definitely
allocated: I see IGD100I VIO ALLOCATED TO DDNAME SYS2 DATACLAS (
) in the system messages.

FWIW, the following works correctly earlier in the same FTP command stream,
so basic DD: is not the problem.

Put //DD:SYS1 'remote.dataset.name'

There are no intervening LOCSITE subcommands.
 
The problem seems to have something to do with the batch program's earlier
processing of z UNIX files. I don't have things diagnosed enough to say "it
fails if the program does X." It "used to work" so the problem is something
subtle.

I'm wondering if anyone has seen this before. Perhaps "oh yeah, you have to
Y if you do X, otherwise you get that." I have tried with and without
setting a DUB default of 1 before the FTP.

The GET subcommand frankly just outright seems correct on its face.

Thanks, and again, apologies that all of the *possibly* relevant detail is
way too voluminous to include. If anyone has a "what about X?" question I
will try to answer it.  

Charles 

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

Re: Discrepancy regarding the real address of the DUCT

[Farley, Peter x23353]

Interesting.  I wonder if "future supervisor function" may include the actual 
ability to USE the various TRAP-related instructions defined in the z 
architecture in application-level (problem state) code running in z/OS.

That would be really nice.  At least some application developers out here in 
the wild have been waiting a long time already for that capability.  It's a bit 
frustrating to have a potentially useful architectural capability not supported 
by the OS you run under.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Cole
Sent: Friday, August 7, 2020 2:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Discrepancy regarding the real address of the DUCT

Thanks Rob. That's pretty much what I was guessing. -Dave


At 8/7/2020 11:43 AM, Rob Scott wrote:
>Dave
>The change in IHASTCB log refers to APAR OA54589 which indicates 
>"support for future supervisor function".
>I am guessing we are not quite in the future enough yet.
>Rob
>
>
>>From: IBM Mainframe Discussion List  On 
>>Behalf Of David Cole
>>Sent: Friday, August 7, 2020 12:10 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Discrepancy regarding the real address of the DUCT EXTERNAL 
>>EMAIL
>>
>>
>>I was researching the disappearance of an STCB field (STCBDUCR) in 
>>z/OS R2.4 maclibs when I noticed a discrepancy that has me puzzled:
>>1) Up until zOS R2.3, the STCBDUCR field used to contain the 31-bit 
>>REAL address of the Dispatchable Unit Control Table (DUCT).
>>2) But in the z/OS R2.4 maclibs, in the STCB mapping macro (IHASTCB), 
>>the STCBDUCR field was removed, and a new 64-bit field was added:
>>STCBDCR8. This is caption as "Real address of the DUCT".
>>3) When a DUCT is active, it's real address is carried in Control 
>>Register 2 ("CR2"). So I went to the -12 edition of Principles (new 
>>with advent of the Z15 machine) to see if the definition of CR2 had changed.
>>4) To my surprise, it had not!
>>- It still describes the DUCTO as... "Bits 33-57 of control register 
>>2, with six zeros appended on the right, form a 31-bit real address 
>>that designates the beginning of the dispatchable- unit control 
>>table".
>>- And it still shows bits 0 thru 32 of CR2 as being reserved!
>>
>>So the discrepancy is this:
>>- The STCB has been prepared to hold an 8-byte wide real address of 
>>the DUCT.
>>- Yet the hardware (i.e. CR2) still only supports a 31-bit real address!
>>
>>
>>Can anyone shed some light on this?
>>
>>TIA
>>Dave Cole
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Discrepancy regarding the real address of the DUCT

[David Cole]

Thanks Rob. That's pretty much what I was guessing. -Dave


At 8/7/2020 11:43 AM, Rob Scott wrote:

Dave
The change in IHASTCB log refers to APAR OA54589 which indicates 
"support for future supervisor function".

I am guessing we are not quite in the future enough yet.
Rob


From: IBM Mainframe Discussion List  On 
Behalf Of David Cole

Sent: Friday, August 7, 2020 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Discrepancy regarding the real address of the DUCT
EXTERNAL EMAIL


I was researching the disappearance of an STCB field (STCBDUCR) in
z/OS R2.4 maclibs when I noticed a discrepancy that has me puzzled:
1) Up until zOS R2.3, the STCBDUCR field used to contain the 31-bit
REAL address of the Dispatchable Unit Control Table (DUCT).
2) But in the z/OS R2.4 maclibs, in the STCB mapping macro (IHASTCB),
the STCBDUCR field was removed, and a new 64-bit field was added:
STCBDCR8. This is caption as "Real address of the DUCT".
3) When a DUCT is active, it's real address is carried in Control
Register 2 ("CR2"). So I went to the -12 edition of Principles (new
with advent of the Z15 machine) to see if the definition of CR2 had changed.
4) To my surprise, it had not!
- It still describes the DUCTO as... "Bits 33-57 of control
register 2, with six zeros appended on the right, form a 31-bit real
address that designates the beginning of the dispatchable-
unit control table".
- And it still shows bits 0 thru 32 of CR2 as being reserved!

So the discrepancy is this:
- The STCB has been prepared to hold an 8-byte wide real address
of the DUCT.
- Yet the hardware (i.e. CR2) still only supports a 31-bit real address!


Can anyone shed some light on this?

TIA
Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: dbc...@colesoft.com
Home page: www.colesoft.com
LinkedIn: www.xdc.com
Facebook: 
www.facebook.com/colesoftware
YouTube: 
www.youtube.com/user/colesoftware

Tools: z/XDC for Assembler debugging
c/XDC for C debugging


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

Re: Edit Macro

[Bob Bridges]

Huh!  I looked for it, and missed it anyway.  Sorry, all.

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

/* Where there’s marriage without love, there will be love without marriage.  
-Poor Richard */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, August 6, 2020 22:38
>
It was mentioned and addressed:

--- On Thu, 6 Aug 2020 20:51:42 -0400, Bob Bridges wrote:
>No one else has mentioned it, so I may be all wet, but don't you have to
>have an ISPF environment to run an ISPF Edit macro?  IKJEFT01 won't do
>itI thought.

--- On Thu, 6 Aug 2020 22:40:40 +, Steely.Mark wrote:
>...
>//SYSTSIN   DD *
>PROFILE PREFIX(xx)
>ISPSTART CMD(%EDITREX1 XXX0111.DATA(DATAXX) - EICUPDT PARM(1))
>/*

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

Re: Discrepancy regarding the real address of the DUCT

[Rob Scott]

Dave

The change in IHASTCB log refers to APAR OA54589 which indicates "support for 
future supervisor function".

I am guessing we are not quite in the future enough yet.

Rob


From: IBM Mainframe Discussion List  On Behalf Of 
David Cole
Sent: Friday, August 7, 2020 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Discrepancy regarding the real address of the DUCT

EXTERNAL EMAIL



I was researching the disappearance of an STCB field (STCBDUCR) in
z/OS R2.4 maclibs when I noticed a discrepancy that has me puzzled:

1) Up until zOS R2.3, the STCBDUCR field used to contain the 31-bit
REAL address of the Dispatchable Unit Control Table (DUCT).

2) But in the z/OS R2.4 maclibs, in the STCB mapping macro (IHASTCB),
the STCBDUCR field was removed, and a new 64-bit field was added:
STCBDCR8. This is caption as "Real address of the DUCT".

3) When a DUCT is active, it's real address is carried in Control
Register 2 ("CR2"). So I went to the -12 edition of Principles (new
with advent of the Z15 machine) to see if the definition of CR2 had changed.

4) To my surprise, it had not!

- It still describes the DUCTO as... "Bits 33-57 of control
register 2, with six zeros appended on the right, form a 31-bit real
address that designates the beginning of the dispatchable-
unit control table".

- And it still shows bits 0 thru 32 of CR2 as being reserved!


So the discrepancy is this:
- The STCB has been prepared to hold an 8-byte wide real address
of the DUCT.
- Yet the hardware (i.e. CR2) still only supports a 31-bit real address!



Can anyone shed some light on this?


TIA
Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: dbc...@colesoft.com

Home page: www.colesoft.com
LinkedIn: www.xdc.com
Facebook: www.facebook.com/colesoftware
YouTube: 
www.youtube.com/user/colesoftware

Tools: z/XDC for Assembler debugging
c/XDC for C debugging



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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Anybody still running a 3270 setup?

[David Spiegel]

4331/4341/4381 perhaps?

On 2020-08-07 11:15, Stefan Skoglund wrote:

lör 2020-08-01 klockan 21:14 + skrev Alexander Huemer:

Hi

Question about 3270, once again.
As you might know, interest in 3270 hardware increased recently, due
to
the emerge of Andrew Kay's oec[0,1].
I have built the required hardware in order to be able to talk to
the
3290 display that I have. Unfortunately this is a DFT terminal that
is
currently not supported. Implementing support for it will only be
possible if protocol traces can be acquired between an establishment
controller and a DFT terminal, hence the question:


LSSM in Pittsburg (Kensington ?) has a 3290 with its accessory, ie 43xx
machine. Though if he have time (and the 4351 ?) takes some power.

--
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: [External] IBM z15 Announcement Letter

[Pommier, Rex]

Sorry, Radoslaw,

I missed the comment about earlier versions aren't there either".  I was 
focusing on the z15 part.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Friday, August 7, 2020 3:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] IBM z15 Announcement Letter

As I wrote it is not the case when the book is not yet available. All other 
books are available, because they are available since GA of z15. 
The same apply to z14 and older machines. And older Announcement Letters (and 
some other documents) also mention Service Guide as one of the books available 
on Resource Link.

Remarks:
1. I see no reason to treat Service Guide differently, but this is not the 
point.
2. The point is IBM claims something different than IBM do with this book.  
Let's imagine IBM says "the only way you can get Service Guide is ., it is 
NOT available on Resource Link because we decided so". OK, their book, their 
decision. However IBM claims "yes, you can get this book from ResourceLink", 
but it is not true.

Personal remarks:
1. I have Service Guide for machines z10-z14.
2. I lack this Guide for z9, z990 and z900 machines and see no way to get it.
3. I've got z15 Service Guide in the past, but it seems I lost it (muddler! 
silly me). However I hope I will get it again. The method is quite simple: some 
friendly person send me this manual. Sometimes it is some IBMer which I don't 
know and he checked whether the book is available to "unwashed masses". 
Nevermind.
4. Unfortunately, this is old true: if you want some document, then keep it on 
your disk (and make backups). Any Internet service can be down when you need 
it, connection may be failing or the service owner may change rules.
5. Most document in huge library are not needed for years, but you never know 
when something is needed...
6. I like this book and I browse/read it. You may call it deviation, but this 
is part of education about the machines.  ;-)

Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 06.08.2020 o 17:29, Pommier, Rex pisze:
> Radoslaw,
>
> The announcement letter says the planned availability date for the 
> enhancements is September 15.  I believe the documentation will be available 
> on that date as well.  In your note below, you quoted them " and will be 
> available at planned availability in the "Library" section of Resource Link:".
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> R.S.
> Sent: Wednesday, August 5, 2020 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] IBM z15 Announcement Letter
>
> I just read IBM Announcement Letter regarding z15 enhancements 
> https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/0/897/ENUS120-050/index.html=en_locale=en
>
> At the bottom they write about documentation.
>
> The following publications are shipped with the product and will be available 
> at planned availability in the "Library" section of Resource Link:
> IBM 8561 Service Guide    GC28-6998
> IBM 8562 Service Guide    GC28-7010
>
> Service Guide. This manual is delivered with MES (upgrade) or with new 
> machine - "shipped with the product".
> However it is NOT available in Resource Link.
> So, the official Letter tells us lies.
>
> It is not just typo, or "books are not yet available". Similar information is 
> mentioned in many previous Letters, but Service Guide is NOT available for 
> z15, z14, z13, etc.
>
> Is it intentional? What is the goal to misinform customers?
>
> Notes:
> 1. This is not classified as "licensed" or "restricted" material. This is one 
> of the books comprising technical documentation available to customer.
> 2. This book is delivered on CD and/or hardcopy. It is delivered with new 
> machine or with MES (upgrade).
> 3. AFAIK this is the only book in such strange state. Other documentation is 
> available on Resource Link. Everything except this one book.
> 4. Do not confuse this Service Guid with similar titles, like Service Guide 
> for HMC, SE, TKE. This manual is for CPC.
>
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>




==

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 

Re: Anybody still running a 3270 setup?

[Stefan Skoglund]

lör 2020-08-01 klockan 21:14 + skrev Alexander Huemer:
> Hi
> 
> Question about 3270, once again.
> As you might know, interest in 3270 hardware increased recently, due
> to 
> the emerge of Andrew Kay's oec[0,1].
> I have built the required hardware in order to be able to talk to
> the 
> 3290 display that I have. Unfortunately this is a DFT terminal that
> is 
> currently not supported. Implementing support for it will only be 
> possible if protocol traces can be acquired between an establishment 
> controller and a DFT terminal, hence the question:
> 

LSSM in Pittsburg (Kensington ?) has a 3290 with its accessory, ie 43xx
machine. Though if he have time (and the 4351 ?) takes some power.

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

Remembering Frances E. Allen

[Dave Jones]

Remembering Frances E. Allen

"If I have seen a little further it is by standing on the shoulders of Giants." 
alas, we lose another great

Source: IBM

https://www.codeproject.com/News.aspx?ntag=19837497732287571&_z=2683912

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

Discrepancy regarding the real address of the DUCT

[David Cole]

I was researching the disappearance of an STCB field (STCBDUCR) in 
z/OS R2.4 maclibs when I noticed a discrepancy that has me puzzled:


1) Up until zOS R2.3, the STCBDUCR field used to contain the 31-bit 
REAL address of the Dispatchable Unit Control Table (DUCT).


2) But in the z/OS R2.4 maclibs, in the STCB mapping macro (IHASTCB), 
the STCBDUCR field was removed, and a new 64-bit field was added: 
STCBDCR8. This is caption as "Real address of the DUCT".


3) When a DUCT is active, it's real address is carried in Control 
Register 2 ("CR2"). So I went to the -12 edition of Principles (new 
with advent of the Z15 machine) to see if the definition of CR2 had changed.


4) To my surprise, it had not!

- It still describes the DUCTO as... "Bits 33-57 of control 
register 2, with six zeros appended on the right, form a 31-bit real 
address that designates the beginning of the dispatchable-

unit control table".

- And it still shows bits 0 thru 32 of CR2 as being reserved!


So the discrepancy is this:
  - The STCB has been prepared to hold an 8-byte wide real address 
of the DUCT.

  - Yet the hardware (i.e. CR2) still only supports a 31-bit real address!



Can anyone shed some light on this?


TIA
Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

Tools:   z/XDC for Assembler debugging
 c/XDC for C debugging

 


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

Re: OT: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

Not a good idea to be hurling insults from a work account.

Joe

On Fri, Aug 7, 2020 at 4:25 AM R.S.  wrote:

> BBC
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
> W dniu 07.08.2020 o 03:28, Seymour J Metz pisze:
> > PKB
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of R.S. 
> > Sent: Thursday, August 6, 2020 5:25 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: OT: OOBOL and English was Re: Still COBOL After All These
> Years?
> >
> > W dniu 05.08.2020 o 17:07, Seymour J Metz pisze:
> >> Must you be so obtuse? The structure that they devised is extremely
> hard to change. Look at how long it took for everyone to switch from the
> Julian Calendar to the Gregorian calendar.
> >>
> >> Yes, Europe has had treaties, and before the ones that you mentioned at
> that, but some things are easier to change than others. Let me know when,
> e.g., Europe gets rid of its royalty (yes, I know that they're mostly
> symbolic.)
> > Must you be so boorish?
> > Must you insult people?
> > Don't you have better hobby? This is not the place for your rudeness,
> > better would be psychiatric office.
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
>
>
>
>
> ==
>
> 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: Edit Macro

[Jeremy Nicoll]

On Thu, 6 Aug 2020, at 23:40, Steely.Mark wrote:

> //SYSTSIN   DD *
> PROFILE PREFIX(xx)
> ISPSTART CMD(%EDITREX1 XXX0111.DATA(DATAXX) - EICUPDT PARM(1))

So the command being issued once ispf is up is

%EDITREX1 XXX0111.DATA(DATAXX) - EICUPDT PARM(1)


> Here is EDITREX1:
> PARSE ARG filename macro1 macro2

so, filename will be   XXX0111.DATA(DATAXX)
 macro1  will be- 
 macro2  will beEICUPDT PARM(1)

And it will not work.

Either you need to change the parse statement to take account of the 
"-" in the incoming argument string, or you need to leave it out of the
arguments.

Either way you should do some basic sanity checking of the values of 
filename, macro1 and macro2   before you use them.  



> ADDRESS ISPEXEC "EDIT DATASET('"filename"') MACRO("macro1") "macro2

> I added macro2 to accept the parm value.
> This is the results:
> 
>>O>   "EDIT DATASET('XXX0111.DATA(DATAXX)') MACRO(EICUPDT) 
> PARM(1)" <---This is the last line that the trace produced

I don't see how it's possible for the code you posted to have produced 
that error.  Why did the "-" in the original ISPSTART command vanish?


-- 
Jeremy Nicoll - my opinions are my own.

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

Re: OT: OOBOL and English was Re: Still COBOL After All These Years?

[R.S.]

BBC

--
Radoslaw Skorupka
Lodz, Poland







W dniu 07.08.2020 o 03:28, Seymour J Metz pisze:

PKB


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



From: IBM Mainframe Discussion List  on behalf of R.S. 

Sent: Thursday, August 6, 2020 5:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT: OOBOL and English was Re: Still COBOL After All These Years?

W dniu 05.08.2020 o 17:07, Seymour J Metz pisze:

Must you be so obtuse? The structure that they devised is extremely hard to 
change. Look at how long it took for everyone to switch from the Julian 
Calendar to the Gregorian calendar.

Yes, Europe has had treaties, and before the ones that you mentioned at that, 
but some things are easier to change than others. Let me know when, e.g., 
Europe gets rid of its royalty (yes, I know that they're mostly symbolic.)

Must you be so boorish?
Must you insult people?
Don't you have better hobby? This is not the place for your rudeness,
better would be psychiatric office.

--
Radoslaw Skorupka
Lodz, Poland






==

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: [External] IBM z15 Announcement Letter

[R.S.]

As I wrote it is not the case when the book is not yet available. All 
other books are available, because they are available since GA of z15. 
The same apply to z14 and older machines. And older Announcement Letters 
(and some other documents) also mention Service Guide as one of the 
books available on Resource Link.


Remarks:
1. I see no reason to treat Service Guide differently, but this is not 
the point.
2. The point is IBM claims something different than IBM do with this 
book.  Let's imagine IBM says "the only way you can get Service Guide is 
., it is NOT available on Resource Link because we decided so". OK, 
their book, their decision. However IBM claims "yes, you can get this 
book from ResourceLink", but it is not true.


Personal remarks:
1. I have Service Guide for machines z10-z14.
2. I lack this Guide for z9, z990 and z900 machines and see no way to 
get it.
3. I've got z15 Service Guide in the past, but it seems I lost it 
(muddler! silly me). However I hope I will get it again. The method is 
quite simple: some friendly person send me this manual. Sometimes it is 
some IBMer which I don't know and he checked whether the book is 
available to "unwashed masses". Nevermind.
4. Unfortunately, this is old true: if you want some document, then keep 
it on your disk (and make backups). Any Internet service can be down 
when you need it, connection may be failing or the service owner may 
change rules.
5. Most document in huge library are not needed for years, but you never 
know when something is needed...
6. I like this book and I browse/read it. You may call it deviation, but 
this is part of education about the machines.  ;-)


Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 06.08.2020 o 17:29, Pommier, Rex pisze:

Radoslaw,

The announcement letter says the planned availability date for the enhancements is September 15.  I 
believe the documentation will be available on that date as well.  In your note below, you quoted 
them " and will be available at planned availability in the "Library" section of 
Resource Link:".

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Wednesday, August 5, 2020 6:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] IBM z15 Announcement Letter

I just read IBM Announcement Letter regarding z15 enhancements 
https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/0/897/ENUS120-050/index.html=en_locale=en

At the bottom they write about documentation.

The following publications are shipped with the product and will be available at planned 
availability in the "Library" section of Resource Link:
IBM 8561 Service Guide    GC28-6998
IBM 8562 Service Guide    GC28-7010

Service Guide. This manual is delivered with MES (upgrade) or with new machine - 
"shipped with the product".
However it is NOT available in Resource Link.
So, the official Letter tells us lies.

It is not just typo, or "books are not yet available". Similar information is 
mentioned in many previous Letters, but Service Guide is NOT available for z15, z14, z13, 
etc.

Is it intentional? What is the goal to misinform customers?

Notes:
1. This is not classified as "licensed" or "restricted" material. This is one 
of the books comprising technical documentation available to customer.
2. This book is delivered on CD and/or hardcopy. It is delivered with new 
machine or with MES (upgrade).
3. AFAIK this is the only book in such strange state. Other documentation is 
available on Resource Link. Everything except this one book.
4. Do not confuse this Service Guid with similar titles, like Service Guide for 
HMC, SE, TKE. This manual is for CPC.



--
Radoslaw Skorupka
Lodz, Poland







==

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 

IBM 3290 Information Panel - Operator's Guide

[Alexander Huemer]

Hi

Would anybody here happen to have a (digital) copy of this document?
I can't seem to find it anywhere.

-Alex

[0] 
https://books.google.com/books/about/IBM_3290_Information_Panel.html?id=w-FsSQAACAAJ_esc=y

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