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&redir_esc=y
--
For IBM-MA
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 availab
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
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
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
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 maclib
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
--
Fo
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
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 requi
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
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@LISTSER
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@LIST
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 D
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
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
EZ
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
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:
>
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
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,
> 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
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 whi
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
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
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,
se
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
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 p
26 matches
Mail list logo
