Re: STORAGE KEY of loaded executable
"In this case, the control program places the module in subpool 252. When choosing between subpools 244 and 251. the control program uses: • Subpool 244 only when within a task that was created by ATTACHX with the KEY=NINE parameter • Subpool 251in all other cases Subpool 244 is not fetch protected and has a storage key equal to your PSW key. Subpool 251 is fetch protected and has a storage key equal to your PSW key. Subpool 252 is not fetch protected and has storage key 0." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Thomas David Rivers [riv...@dignus.com] Sent: Sunday, January 31, 2021 6:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: STORAGE KEY of loaded executable I have a situation where I LOAD a program, with a PSW KEY of 8, then branch to it. The program switches to KEY 9, but wants to reference some data in the loaded CSECT (say, for example, a =F constant in the literal area.) This blows up, I'm guessing because the key isn't the same as the loaded module's memory (the address appears to be fine.) This brings up a couple of questions: When you LOAD a program, how do you control the KEY for the memory the LOAD'd program occupies? Can you, or does z/OS always LOAD (non-auth) programs in KEY=8? When you switch KEYs, how do you retain access to the program's memory for constants and things? And - to get more complicated - when a blob of AUTHORIZED code loads something, say, some system exit or something; what is the STORAGE KEY of the memory that code is loaded in. That program may get entered with a KEY=0, but will need access to it's own CSECT. And - It's not quite clear to me, but does the STORAGE KEY get examined during the fetch-execute cycle of program execution. If my module is in memory with KEY=8, and I change the key with an SPKA instruction; can I actually retrieve the next instruction to execute? Just where does the key-check occur? - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://secure-web.cisco.com/14WxsDY-ayEIw4Txd4CUMcWempgt1bm-X7QTZLrVnB1i6y_TA8841bEosQ2fvFaGtux7s2inbpaPacpuiMargzng8gwxFV5gOEoaTqqAVgLlVYVvpTX2b8HEPP7qMh32meHrzoDeYi2YlVQSamQ6-5nyyePmZACHdPPnhUvNFSMsPQLj-4l8ESe4ScBrJfxBMIHHKL2yQwzbh8HI3XoyU_GR8mttfo6SMzk6InfeXYnQxY4NusZuxHoEyR2dPPaP-Z-X9x6iVDSEyz0XmBMh2V9XS7D-WNOSRJI_UP0aL0jgj67GzxbodARuYB0l7Spm8fL2KJjam5mKuznS8nPE3NzMsL-xju1mRq3tY0IrtZmxs7JWt_YMmIWy1oG3T82MK-nf30qmZ5Ad5Hnoaw941mHq5tx8ddGWQ_fD4wybqxyPy0EysALY5YXjajS7ipLcO/http%3A%2F%2Fwww.dignus.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
X3270 or c3270 on mac
I've seen this mentioned here before. Would anyone who is using mind sharing your key map file? I'm playing around with it on my Mac. Looking for a headscarf. Thanks, dave 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
STORAGE KEY of loaded executable
I have a situation where I LOAD a program, with a PSW KEY of 8, then branch to it. The program switches to KEY 9, but wants to reference some data in the loaded CSECT (say, for example, a =F constant in the literal area.) This blows up, I'm guessing because the key isn't the same as the loaded module's memory (the address appears to be fine.) This brings up a couple of questions: When you LOAD a program, how do you control the KEY for the memory the LOAD'd program occupies? Can you, or does z/OS always LOAD (non-auth) programs in KEY=8? When you switch KEYs, how do you retain access to the program's memory for constants and things? And - to get more complicated - when a blob of AUTHORIZED code loads something, say, some system exit or something; what is the STORAGE KEY of the memory that code is loaded in. That program may get entered with a KEY=0, but will need access to it's own CSECT. And - It's not quite clear to me, but does the STORAGE KEY get examined during the fetch-execute cycle of program execution. If my module is in memory with KEY=8, and I change the key with an SPKA instruction; can I actually retrieve the next instruction to execute? Just where does the key-check occur? - Dave R. - -- 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
Re: ISPF for mainframe Linux
Never heard of a Version 4.10 of SPF/PC. Perhaps that was in the US and not in the UK. AFAIK The last version of SPF/PC distributed on floppy disks was 4.0.6 - with the final 4.0.7 fix available for download only from CTC's bulletin board (when it was still around, in 1995). After that, CTC switched to distributing only their new Windoze-based SPF/SE - which did not support REXX or keyboard remapping, and was just a heap of cr*p when compared with SPF/PC. But if whatever you have with Version V4.10 works OK for you, great ;-) Cheers, Chris Poncelet (retired sysprog) On 28/01/2021 00:34, Lennie Dymoke-Bradshaw wrote: > Yes, I found I have Version 4.10 of this program. > It took me quite a while to find the floppy disk it was on, about another 15 > minutes to find my USB attached floppy disk reader, then about 30 minutes to > get it to work under vDOS under Windows 10 64-bit. But it still works. > > Lennie Dymoke-Bradshaw > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > CM Poncelet > Sent: 27 January 2021 00:28 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ISPF for mainframe Linux > > I still have and use the last version of SPF/PC (4.0.7) from CTC. It's a DOS > program with an in-built DOS extender. CTC stopped supporting it in the > 1990's. > > On 26/01/2021 15:21, PINION, RICHARD W. wrote: >> Does anybody remember an ISPF product that ran under mainframe Linux >> from the early 2000's? And, does anybody remember Command Technology >> Corporation's SPF/PC? Just walking down memory lane. >> Confidentiality notice: >> This e-mail message, including any attachments, may contain legally >> privileged and/or confidential information. If you are not the intended >> recipient(s), or the employee or agent responsible for delivery of this >> message to the intended recipient(s), you are hereby notified that any >> dissemination, distribution, or copying of this e-mail message is strictly >> prohibited. If you have received this message in error, please immediately >> notify the sender and delete this e-mail message from your computer. >> >> -- >> 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: Inspecting and extracting from /OS transportable files on other platforms?
If none of your data are binary, all character data use the same EBCDIC code page and all the characters exist in the target code page then that will work as far as visual fidelity is concerned. If you intend to use the data with a language processor then you also need to ensure that it supports the code point assignments of that code page. As an example, some implementations of REXX expect ¬ at 'AA'X while others expect it at 'AC'X. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, January 31, 2021 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inspecting and extracting from /OS transportable files on other platforms? On Sat, 30 Jan 2021 17:35:57 +0100, Bernd Oppolzer wrote: > >The problem is not at the client side (ASCII codepages); >the problem is that the EBCDIC codepages in Europe have the >exclamation point (!) at the place, where the American EBCDIC has |, >and so, if you transfer from an European EBCDIC codepage (273, for >example), >which is standard here in Europe, you will get exclamation points >instead of | >on the PC. > I'd expect the other way around: that I'd get '|' where an exclamation point appears in CP 273. But is there a case where FTP SITE SBDataconn does not suffice with built-in code pages? -- 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: Inspecting and extracting from /OS transportable files on other platforms?
Yes, EBCDIC code pages are a mare's nest, even from a US-centric perspective.
IND$FILE uses a 3270 datastream and runs within your TSO session. WSA uses an
SNA or TCP/IP session totally independent of your 3270 session, and supports
ISPF running in batch.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Sunday, January 31, 2021 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other
platforms?
Am 31.01.2021 um 15:19 schrieb Paul Gilmartin:
> On Sat, 30 Jan 2021 17:35:57 +0100, Bernd Oppolzer wrote:
>> The problem is not at the client side (ASCII codepages);
>> the problem is that the EBCDIC codepages in Europe have the
>> exclamation point (!) at the place, where the American EBCDIC has |,
>> and so, if you transfer from an European EBCDIC codepage (273, for
>> example),
>> which is standard here in Europe, you will get exclamation points
>> instead of |
>> on the PC.
>>
> I'd expect the other way around: that I'd get '|' where an exclamation
> point appears in CP 273.
Maybe this is true, too.
>
> But is there a case where FTP SITE SBDataconn does not suffice
> with built-in code pages?
>
> -- gil
Let me try to explain the problem from a German mainframe programmer's
point of view,
who is using European EBCDIC codepages since the early 1980s.
For languages like PL/1 and REXX, who don't have both ! and | as
language elements,
the difference between US EBCDIC and Euro EBCDIC concerning those
characters
is not really a problem; we are accustomed to use ! instead of |, when
programming
PL/1 or REXX ... the concatenation is done using !! in both languages;
when downloading sources to the PC, we also get !! and the German umlauts
and all works well ...
as long as we don't try to run the programs on the PC or to upload the
sources
to a machine which uses US EBCDIC ... then we run into problems.
Then came C (around the early 1990s), and suddenly we were in big trouble,
because both | and ! are part of the language
and { and }, which turned out to be ä and ü in our Euro EBCDIC - the C
sources
looked horrible at our mainframe terminals.
(At that time, we did not use FTP, BTW, to send to sources to the
mainframe;
the tools were IND$FILE or something called workstation agent ... maybe
using
IND$FILE under the cover. You started the editing session on the mainframe,
but then the file was transferred to the PC and a local editing window
on the
PC opened; when saving the file, it was re-transferred to the mainframe.
Big fun :-) ...)
And so we had to translate all our programs (which we prepared and
tested on
the PC) to trigraphs etc., because the early C compilers only supported
US EBCDIC.
Today it is much better, because the C compiler can be controlled to
understand
whatever codepage you want (at a certain point in time, this was true
for the
C compiler, but not for the DB2 preprocessor, so we had to stay with the
trigraph mechanism for C/DB2-programs).
--
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: Inspecting and extracting from /OS transportable files on other platforms?
Am 31.01.2021 um 15:19 schrieb Paul Gilmartin:
On Sat, 30 Jan 2021 17:35:57 +0100, Bernd Oppolzer wrote:
The problem is not at the client side (ASCII codepages);
the problem is that the EBCDIC codepages in Europe have the
exclamation point (!) at the place, where the American EBCDIC has |,
and so, if you transfer from an European EBCDIC codepage (273, for
example),
which is standard here in Europe, you will get exclamation points
instead of |
on the PC.
I'd expect the other way around: that I'd get '|' where an exclamation
point appears in CP 273.
Maybe this is true, too.
But is there a case where FTP SITE SBDataconn does not suffice
with built-in code pages?
-- gil
Let me try to explain the problem from a German mainframe programmer's
point of view,
who is using European EBCDIC codepages since the early 1980s.
For languages like PL/1 and REXX, who don't have both ! and | as
language elements,
the difference between US EBCDIC and Euro EBCDIC concerning those
characters
is not really a problem; we are accustomed to use ! instead of |, when
programming
PL/1 or REXX ... the concatenation is done using !! in both languages;
when downloading sources to the PC, we also get !! and the German umlauts
and all works well ...
as long as we don't try to run the programs on the PC or to upload the
sources
to a machine which uses US EBCDIC ... then we run into problems.
Then came C (around the early 1990s), and suddenly we were in big trouble,
because both | and ! are part of the language
and { and }, which turned out to be ä and ü in our Euro EBCDIC - the C
sources
looked horrible at our mainframe terminals.
(At that time, we did not use FTP, BTW, to send to sources to the
mainframe;
the tools were IND$FILE or something called workstation agent ... maybe
using
IND$FILE under the cover. You started the editing session on the mainframe,
but then the file was transferred to the PC and a local editing window
on the
PC opened; when saving the file, it was re-transferred to the mainframe.
Big fun :-) ...)
And so we had to translate all our programs (which we prepared and
tested on
the PC) to trigraphs etc., because the early C compilers only supported
US EBCDIC.
Today it is much better, because the C compiler can be controlled to
understand
whatever codepage you want (at a certain point in time, this was true
for the
C compiler, but not for the DB2 preprocessor, so we had to stay with the
trigraph mechanism for C/DB2-programs).
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inspecting and extracting from /OS transportable files on other platforms?
On Sat, 30 Jan 2021 17:35:57 +0100, Bernd Oppolzer wrote: > >The problem is not at the client side (ASCII codepages); >the problem is that the EBCDIC codepages in Europe have the >exclamation point (!) at the place, where the American EBCDIC has |, >and so, if you transfer from an European EBCDIC codepage (273, for >example), >which is standard here in Europe, you will get exclamation points >instead of | >on the PC. > I'd expect the other way around: that I'd get '|' where an exclamation point appears in CP 273. But is there a case where FTP SITE SBDataconn does not suffice with built-in code pages? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF for mainframe Linux
Once again you are lying about what others think. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Crayford [dcrayf...@gmail.com] Sent: Sunday, January 31, 2021 3:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF for mainframe Linux To summarize: 1. You don't think it's necessary to have editor features like code completion, refactoring, hover-help, syntax highlighting or static code analysis. 2. Writing macros is an absolute must even if the editor that you use provides commands and key mappings so there is no requirement to write macros. 3. Modern editors and/or the back-end/protocols that they use are stupid and we should all just stick to Tritus-SPF. 4. If anybody disagrees with any of the above then they are talking nonsense and nobody on this newsgroup agrees with them? Is that about right? Please don't bother replying. You always seem to want to have to last word I am so incredibly bored by it all now. As I suspect everybody else is. On 31/01/2021 3:55 pm, Seymour J Metz wrote: > Whoosh! A syntax direct editor is a frequent component of an IDE > > What seems to you is, as usual, wrong. Meanwhile, you are hypocritically > doing exactly what you accuse me of and not even trying to understand what I > and others have written. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > David Crayford [dcrayf...@gmail.com] > Sent: Sunday, January 31, 2021 2:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ISPF for mainframe Linux > > On 31/01/2021 10:49 am, Seymour J Metz wrote: >> Did it ever occur to you that when you write things that people know to be >> false, they're less likely to believe what you write about other matters? > > Shrug! I could care less what you think. You're understanding of > mainframe technology seems to be chained to the past. Hence why you take > so many endless trips down memory lane. > > >> BTW, syntax directed editors have been around longer than three decades, >> regardless of when you first discovered them. > > I don't remember mentioning syntax directed editors? I was talking about > LSP and using a client/server architecture to decouple the editor from > language specific features like > context assist, hover over, auto-completion and advanced static code > analyzers. Any editor that is an LSP client can uses IBM's free COBOL, > PL/1, HLASM language servers. And that is pretty much > every popular editor including Vim (neovim). Zowe has mainframe specific > editors that use LSP. There are also many commercial products coming > online from mainframe vendors that > use LSP. It seems to me that you don't even bother trying to understand > what I'm talking about. You just hit reply and start typing lots of > pompous, ignorant drivel. > > -- > 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: ISPF for mainframe Linux
To summarize: 1. You don't think it's necessary to have editor features like code completion, refactoring, hover-help, syntax highlighting or static code analysis. 2. Writing macros is an absolute must even if the editor that you use provides commands and key mappings so there is no requirement to write macros. 3. Modern editors and/or the back-end/protocols that they use are stupid and we should all just stick to Tritus-SPF. 4. If anybody disagrees with any of the above then they are talking nonsense and nobody on this newsgroup agrees with them? Is that about right? Please don't bother replying. You always seem to want to have to last word I am so incredibly bored by it all now. As I suspect everybody else is. On 31/01/2021 3:55 pm, Seymour J Metz wrote: Whoosh! A syntax direct editor is a frequent component of an IDE What seems to you is, as usual, wrong. Meanwhile, you are hypocritically doing exactly what you accuse me of and not even trying to understand what I and others have written. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Crayford [dcrayf...@gmail.com] Sent: Sunday, January 31, 2021 2:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF for mainframe Linux On 31/01/2021 10:49 am, Seymour J Metz wrote: Did it ever occur to you that when you write things that people know to be false, they're less likely to believe what you write about other matters? Shrug! I could care less what you think. You're understanding of mainframe technology seems to be chained to the past. Hence why you take so many endless trips down memory lane. BTW, syntax directed editors have been around longer than three decades, regardless of when you first discovered them. I don't remember mentioning syntax directed editors? I was talking about LSP and using a client/server architecture to decouple the editor from language specific features like context assist, hover over, auto-completion and advanced static code analyzers. Any editor that is an LSP client can uses IBM's free COBOL, PL/1, HLASM language servers. And that is pretty much every popular editor including Vim (neovim). Zowe has mainframe specific editors that use LSP. There are also many commercial products coming online from mainframe vendors that use LSP. It seems to me that you don't even bother trying to understand what I'm talking about. You just hit reply and start typing lots of pompous, ignorant drivel. -- 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
