Thanks,
John
/* REXX */
address ISPEXEC
dsn = user.load
"LIBDEF ISPLLIB DATASET ID("dsn")"
"SELECT CMD(assemb1)"
/* assemb1 is the assembler routine that issues the load */
"LIBDEF ISPLLIB"
exit
ISPF will invoke assemb1 as a command processor
and assemb1 will be attached under the ISPTASK TCB
with user.load as a TASKLIB. Hence the load issued by
assemb1 will be found. The one big exception would be
if either of assemb1 or the loaded routine issues a SELECT PGM
service. This would get run at the ISPTASK TCB and could cause
modules not found if it issued load macros. This does not appear to
be the case you descibed though.
With this example both routines may be in the LIBDEF'd load module.
Marvin Knight
ISPF Development
"Bodoh, John R" <john....@EDS.COM>@listserv.nd.edu> on 11/27/2000
06:09:57 PM
Please respond to ISPF discussion list <ISP...@listserv.nd.edu>
Sent by: ISPF discussion list <ISP...@listserv.nd.edu>
To: ISP...@listserv.nd.edu
cc:
Subject: ISPLLIB and the TASKLIB
The first assembler routine is a REXX function. I don't see how I use your
suggestion. The actual sequence is:
REXX1 exec:
Do LIBDEFs and ALTLIB
Invoke mainline REXX2 with SELECT CMD(%REXX2) NEWAPPL(XXX) PASSLIB
REXX2 exec:
Invoke function initialization as: X = ASMLOAD1("INIT")
ASMLOAD1 load module:
Issue LOAD macro for ASMLOAD2 in same load library. --->806
Thanks,
John
the 806 is because ISPLLIB is honoured only for the function call.
Subsequent calls will ignore this DD. Allocation of steplib might help.
Otherwise, try ADDRESS TSO "CALL 'library.where.asmload1.resides(ASMLOAD1)'
'INIT' "
Because the TSO CALL attaches the module, subsequent LOAD instructions
search the
attached library first.
Greetings,
Richard
> -----Ursprüngliche Nachricht-----
> Von: Bodoh, John R [SMTP:john....@EDS.COM]
> Gesendet am: Dienstag, 28. November 2000 14:07
> An: ISP...@LISTSERV.ND.EDU
> Betreff: Re: ISPLLIB and the TASKLIB
Ted .MacNEIL@ScotiaBank.COM
Phone: 1-416-288-3829
Fax: 1-416-288-4400
<Time for a new tag line>
Hope this helps,
Mark Hammack
mailto:lmha...@msn.com
The problem with TSOLIB is that it has to be used from the READY prompt.
What I have is a selection from a panel that starts the application.
Thanks,
John
-----Original Message-----
From: Ted MacNEIL [mailto:ted.m...@SCOTIABANK.COM]
Sent: Tuesday, November 28, 2000 6:15 AM
To: ISP...@listserv.nd.edu
I tried it and it doesn't work. I cannot issue 'SELECT CMD(ASMLOAD1 INIT)'
because ASMLOAD1 operates as a REXX function (i.e., it expects an EFPL in
register one.
Thanks,
John
-----Original Message-----
From: Mark Hammack [mailto:lmha...@SYSTEMWARE-INC.COM]
Sent: Tuesday, November 28, 2000 7:17 AM
To: ISP...@listserv.nd.edu
Subject: Re: ISPLLIB and the TASKLIB
John, I don't know if this will work or not, but I tried a similar scenario
here with good results. In REXX1, set the application id BEFORE you use
LIBDEF services (I use a recursive call to REXX1 to set the correct applid).
Then DON'T use NEWAPPL or PASSLIB on the 'SELECT CMD' for REXX2. In REXX2,
issue 'SELECT CMD(ASMLOAD1 INIT)' (you may have to play around with ASMLOAD1
to let it recognize the parms coming in since the format is different
between 'SELECT CMD and SELECT PGM', if you need an example, e-mail me).
Hope this helps,
Mark Hammack
mailto:lmha...@msn.com
-----Original Message-----
From: Bodoh, John R [mailto:john....@EDS.COM]
Sent: Tuesday, November 28, 2000 7:07 AM
To: ISP...@listserv.nd.edu
Subject: Re: ISPLLIB and the TASKLIB
Marvin,
The first assembler routine is a REXX function. I don't see how I use your
suggestion. The actual sequence is:
REXX1 exec:
Do LIBDEFs and ALTLIB
Invoke mainline REXX2 with SELECT CMD(%REXX2) NEWAPPL(XXX) PASSLIB
REXX2 exec:
Invoke function initialization as: X = ASMLOAD1("INIT")
ASMLOAD1 load module:
Issue LOAD macro for ASMLOAD2 in same load library. --->806
Thanks,
John
(1) I don't know how to do it.
(2) I don't think it's a good idea
(3) I don't want to take the time to explain it
(4) Management says to say it's impossible
My guess is (1),
You have several options. First, check the ISPF documentation. There is a
discussion of when ISPF does an ATTACH with TASKLIB.
Second, your first subroutine could OPEN a DCB and do a LOAD with DCB=.
It's also possible to get a TASKLIB without going through ISPEXEC SELECT,
but it's probably more work than it's worth.
Shmuel (Seymour J.) Metz
Shmuel (Seymour J.) Metz
Regards,
John Kalinich
"Metz, Seymour" <sm...@NSF.GOV>@listserv.nd.edu> on 11/28/2000 10:52:01 AM
Please respond to ISPF discussion list <ISP...@listserv.nd.edu>
Sent by: ISPF discussion list <ISP...@listserv.nd.edu>
To: ISP...@listserv.nd.edu
cc:
Subject: Re: AW: ISPLLIB and the TASKLIB
I have read the ISPF book about TASKLIB many time trying to figure a way. I
submitted an ETR to IBM and their answer so far I can't find documented
anywhere. Here is the response:
"The initial EXEC runs at one task level. The SELECT CMD causes a
daughter task to be created, with the LIBDEF datasets as the
tasklib. However, the program run as result of the REXX function
call runs in a sister task (ie at the same TTCB level) as the
initial EXEC, which does not have the LIBDEF TASKLIB. The REXX
function program is invoked by a LINK with the DCB parameter, for
the LIBDEF datasets, so it is found, but the TASKLIB is not
propageted, and thus the LOAD from the program fails. The sister
task will have the TASKLIB environment of the original ISPF
invocation, so that is why it works when the load library is
allocated
before starting ISPF"
Thanks,
John
-----Original Message-----
From: Metz, Seymour [mailto:sm...@NSF.GOV]
Sent: Tuesday, November 28, 2000 9:07 AM
To: ISP...@listserv.nd.edu
Subject: Re: ISPLLIB and the TASKLIB
Impossible:
(1) I don't know how to do it.
(2) I don't think it's a good idea
(3) I don't want to take the time to explain it
(4) Management says to say it's impossible
My guess is (1),
You have several options. First, check the ISPF documentation. There is a
discussion of when ISPF does an ATTACH with TASKLIB.
Second, your first subroutine could OPEN a DCB and do a LOAD with DCB=.
It's also possible to get a TASKLIB without going through ISPEXEC SELECT,
but it's probably more work than it's worth.
Shmuel (Seymour J.) Metz
Marv
Marvin Knight
ISPF Development
"Bodoh, John R" <john....@EDS.COM>@listserv.nd.edu> on 11/28/2000
08:06:57 AM
Please respond to ISPF discussion list <ISP...@listserv.nd.edu>
Sent by: ISPF discussion list <ISP...@listserv.nd.edu>
To: ISP...@listserv.nd.edu
cc:
Subject: Re: ISPLLIB and the TASKLIB
Marvin,
The first assembler routine is a REXX function. I don't see how I use your
suggestion. The actual sequence is:
REXX1 exec:
Do LIBDEFs and ALTLIB
Invoke mainline REXX2 with SELECT CMD(%REXX2) NEWAPPL(XXX) PASSLIB
REXX2 exec:
Invoke function initialization as: X = ASMLOAD1("INIT")
ASMLOAD1 load module:
Issue LOAD macro for ASMLOAD2 in same load library. --->806
Thanks,
John
-----Original Message-----
From: Marvin Knight [mailto:kni...@US.IBM.COM]
Sent: Monday, November 27, 2000 6:43 PM
To: ISP...@listserv.nd.edu
Subject: Re: ISPLLIB and the TASKLIB
John,
If you invoke the first assembler routine as a
command processor the LIBDEF can work.
/* REXX */
address ISPEXEC
dsn = user.load
"LIBDEF ISPLLIB DATASET ID("dsn")"
"SELECT CMD(assemb1)"
/* assemb1 is the assembler routine that issues the load */
"LIBDEF ISPLLIB"
exit
ISPF will invoke assemb1 as a command processor
and assemb1 will be attached under the ISPTASK TCB
with user.load as a TASKLIB. Hence the load issued by
assemb1 will be found. The one big exception would be
if either of assemb1 or the loaded routine issues a SELECT PGM
service. This would get run at the ISPTASK TCB and could cause
modules not found if it issued load macros. This does not appear to
be the case you descibed though.
With this example both routines may be in the LIBDEF'd load module.
Marvin Knight
ISPF Development
"Bodoh, John R" <john....@EDS.COM>@listserv.nd.edu> on 11/27/2000
06:09:57 PM
Please respond to ISPF discussion list <ISP...@listserv.nd.edu>
Sent by: ISPF discussion list <ISP...@listserv.nd.edu>
To: ISP...@listserv.nd.edu
cc:
Subject: ISPLLIB and the TASKLIB
I have a REXX EXEC that invokes another REXX EXEC that uses a load module
as
a function. The load module is written assembler and uses the LOAD macro
for a second load module. So I need to have a TASKLIB allocated at the
time
the load module is invoked. I tried LIBDEF but that didn't work. I talked
to IBM and they said what I wanted to do was impossible. I can't beliieve
that. Any ideas?
There must by something I am doing wrong. Can anyone help?
Thanks,
John
Shmuel (Seymour J.) Metz
My application will be executed as an option from a panel that contains many
applications. So, it has to be invoked within ISPF. Dataset cannot be
pre-allocated on the chance that the user might select my application to
execute. If the ISPLLIB is pre-allocated prior to invoking ISPF, everything
works. But that can't be done.
Thanks,
John
-----Original Message-----
From: Metz, Seymour [mailto:sm...@NSF.GOV]
Sent: Tuesday, November 28, 2000 11:46 AM
To: ISP...@listserv.nd.edu
Subject: Re: AW: ISPLLIB and the TASKLIB
ISPF -->ISPMAIN
|
| (attach tasklib=ISPLLIB)
|
ISPTASK
|
_______________________
|
|
| (attach) |
(attach tasklib=libdef'd ISPLLIB )
EXEC (Rexx) exec CMD1
The above is how the ISPF task structure will look running a REXX
exec if the REXX EXEC issues a LIBDEF for ISPLLIB and then issues
a SELECT CMD for CMD1. The original ISPLLIB is a tasklib for the
ISPTASK TCB. All ISPF services are run at the ISPTASK TCB. To
use LIBDEF with ISPLLIB for a tasklib scenario you must issue a
SELECT CMD for a command processor. This sets up the tasklib
environment you need. Note that any ISPF services issed by CMD1
would be run at the ISPTASK TCB. For instance, a SELECT PGM
issued by CMD1 would be run at the ISPTASK TCB via a LINK macro
with DCB=Libdef'd DCB. Also notice that there is no TASKLIB for
the attach of a REXX EXEC.
For split screens, there is an ISPTASK for each screen.
Marvin Knight
ISPF Development
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Bodoh, John R [SMTP:john....@EDS.COM]
I am not rigid in my stucture or in my design. I do have the following
requirements:
1. Application is invoked by an option on a panel full of OEM and third
party applications.
2. Cannot pre-allocate any datasets prior to user selection of
application. Likewise, cannot
have a STEPLIB.
3. Application uses load module at an interface to DB2 (the interface
was under developement
before IBM came out with their support). The load module must issue
a LOAD for DSNALI and
others.
Thanks,
John
-----Original Message-----
From: Marvin Knight [mailto:kni...@US.IBM.COM]
Sent: Tuesday, November 28, 2000 10:59 AM
To: ISP...@listserv.nd.edu
Subject: Re: ISPLLIB and the TASKLIB
John,
Marv
Marvin Knight
ISPF Development
Marvin,
REXX2 exec:
ASMLOAD1 load module:
Thanks,
John
Roland
Thomas Berg
"Bodoh, John R" skrev:
I have tried several editors with ISPF client/server and found most don't
work correctly. The manual is of little help simple stating you can use your
favorite PC editor.
I also have found differences in how ISPF client/server works between OS/390
2.6 and 2.8. An editor that partially worked in 2.6 doesn't in 2.8.
Editors I have found to work are Notepad, PFE, THE, txtedit. One that don't
are synedit, Preditor(from Compuware), xpad, editpadlite and all the free
notepad replacements I tried (cnotepad, notepad+ etc). Preditor partially
worked in 2.6 I could load a file from the mainframe but couldn't save it.
Now however Preditor ( and most editors I try) seems stuck in loop with
smss.exe, csrss.exe and
wsa.exe and the editor using all CPU time till I kill the editor.
Is anyone using an editor other than notepad?
What if I don't have a favorite PC editor? They all suck. If any of
'em were any good there wouldn't be so many of 'em. If CTC weren't
bozos and continued to support the old-style SPF/PC, that would be
my choice. So my favorite editor now is still the one in ISPF. No
fooling with ISPF C/S.
/Leonard
> If CTC weren't bozos and continued to support the old-style SPF/PC
Throwing in my two sense, I still have SPF/PC v4.0 for OS/2-Dos. It is one the best editors on the PC, and is THE best line editor...ever.
CTC went the way of morons.
dvn
-----Original Message-----
From: Leonard Woren [mailto:l...@BEST.COM]
Sent: Friday, December 01, 2000 9:21 PM
To: ISP...@listserv.nd.edu
Roy
--------------------------------------------------------------------------------------------
"National Westminster Bank plc is registered in England No 929027. Registered Office: 135 Bishopsgate, London EC2M 3UR.
National Westminster Bank plc is regulated by IMRO, SFA and Personal Investment Authority. A member of the NatWest and Gartmore Marketing Group advising on the life assurance, pensions and unit trust products only of that Marketing Group.
This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer.
Internet e-mails are not necessarily secure. National Westminster Bank plc does not accept responsibility for changes made to this message after it was sent."
--------------------------------------------------------------------------------------------
Shmuel (Seymour J.) Metz
Considering that CTC advertised "zero learning curve" but couldn't be
bothered to address compatibility issues, I'd have to say that the did that
a long time ago.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Don Nielsen [SMTP:Do...@CMSCMS.COM]
> Sent: Monday, December 04, 2000 9:14 AM
>
> Throwing in my two sense, I still have SPF/PC v4.0 for OS/2-Dos. It is
> one the best editors on the PC, and is THE best line editor...ever.
>
Didn't they go out of business a few years ago? I tried Tritus SPF
5-6 years ago. I compared open and save times with SPF/PC, and one
was much faster, the other much slower. They had me look at a few
memory management settings, but were basically uninterested in
finding the problem. I shipped the product back to them.
> Considering that CTC advertised "zero learning curve" but couldn't be
> bothered to address compatibility issues, I'd have to say that the did that
> a long time ago.
Ok...
WHEREAS there are no good PC editors
WHEREAS many users like ISPF edit
WHEREAS CTC are bozos
WHEREAS Tritus is out of business
THEREFORE IBM should port ISPF edit to the PC platform.
/Leonard
A full ISPF port to OS/2, or even Linux, would be very nice.
Shmuel (Seymour J.) Metz
To make the project cost-effective, I'd settle for a port of only
options 1, 2, and 3.4 (DSLIST). On the other hand, I'd also like
to be able to write my own panels and Rexx dialogs...
I still use OS/2, but the handwriting is on the wall (in 5 gallon
buckets), so I think a Win2000 port is also necessary in addition
to OS/2 and Linux. Now would be the time for ISPF to un-OCO.
Hmmm... Drat. How could ISPF be ported to non-390 platforms?
Isn't it written mostly in PL/S or whatever today's name for it is?
Maybe IBM could develop an alternative PL/S compiler that puts out
C source instead of assembler source?
/Leonard
Clark Morris, CFM Technical Programming Services Inc., cfm...@istar.ca
PL/S (BSL, PL/X) includes the GENERATE statement; the assembler code is
passed through. Translating that to a different architecture is definitely
non-trivial. I suspect that a rewrite is more likely. Besides, I'd want a
Linux version to be integrated with one of the common desktops, e.g., KDE,
and that would definitely be a rewrite.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Leonard Woren [SMTP:l...@BEST.COM]
In the meantime, if any of you has a copy of Tritus/SPF for sale please
drop me a note.
Thanks,
Mike
>In the meantime, if any of you has a copy of Tritus/SPF for sale please
>drop me a note.
If they're out of business, can't we just give it away?
Frank Clarke
Tampa Area REXX Programmers' Alliance
REXX Language Assn
Join us at www.rexxla.org
>To make the project cost-effective, I'd settle for a port of only
>options 1, 2, and 3.4 (DSLIST). On the other hand, I'd also like
>to be able to write my own panels and Rexx dialogs...
A variant of option 3.3 for directories (folders) would be useful.
Imagine option 6 (enter MS/DOS command) - should not be too hard
to implement.
As far as PC editors, I used to use one which was essentially
a port of vi (now don't barf), and allowed me to edit in the
style of vi and Notepad in the same editing session.
- seb
Shmuel (Seymour J.) Metz
Thomas Berg
"Clark F. Morris, Jr." skrev:
>
> I think that PL/? is now at least somewhat cross platform. Would the
> porting be difficult because of the differences between the GUI
> environment of the PC versus the text based environment of the 327x?
> Who besides mainframe people would use it? Is their a lack in the other
> editors that support the Windows and Unix/Linux environments that ISPF
> fills for those environments?
>
> Clark Morris, CFM Technical Programming Services Inc., cfm...@istar.ca
>
> Leonard Woren wrote:
> >
> > On Tue, Dec 05, 2000 at 11:28:52AM -0500, Metz, Seymour (sm...@NSF.GOV) wrote:
> > > A full ISPF port to OS/2, or even Linux, would be very nice.
> >
> > To make the project cost-effective, I'd settle for a port of only
> > options 1, 2, and 3.4 (DSLIST). On the other hand, I'd also like
> > to be able to write my own panels and Rexx dialogs...
> >
> > I still use OS/2, but the handwriting is on the wall (in 5 gallon
> > buckets), so I think a Win2000 port is also necessary in addition
> > to OS/2 and Linux. Now would be the time for ISPF to un-OCO.
> >
> > Hmmm... Drat. How could ISPF be ported to non-390 platforms?
> > Isn't it written mostly in PL/S or whatever today's name for it is?
> > Maybe IBM could develop an alternative PL/S compiler that puts out
> > C source instead of assembler source?
> >
> > /Leonard
I'm not terribly interested in GUI stuff. It could run quite well
in a text (VIO) window, just like SPF/PC and TSPF.
> Who besides mainframe people would use it?
I don't know how to answer that. I think that there could be non-
mainframe people who might recognize the power of ISPF edit. It's
probably possible to do everything in emacs that you can do in ISPF
edit, but the learning curve is much higher. How many people know
lisp?
One powerful, easy to use, easily available for many platforms editor
could develop a large following. As I said before, if any of the PC
& *ix editors were any good, would there be so many of them?
> Is their a lack in the other
> editors that support the Windows and Unix/Linux environments that ISPF
> fills for those environments?
Not if you don't mind having to memorize a half a zillion non-mnemonic
Control-blah commands, and don't mind the damage that constant use of
the Control key might be causing.
Here's a trivial example. Tell me how, using MS Word or Notepad, to
mark a huge block of text in order to move it or delete it. With
ISPF edit, you find the first line, put DD or MM, find the last line,
DD or MM, and you're done. Mouse-cursor marking of large blocks of
text is very painful. Try marking 10,000 lines this way. Trivial
in ISPF edit, a nightmare in most other editors as far as I know.
(I actually know how to do this in emacs, but emacs wears out my
control-key finger.) How would you do the following with your
favorite pc or *ix editor (not counting emacs):
X ALL
F ALL foo word 20 30 .A .B
C ALL NX bar bletch 65 75
(The string being changed has no relation to the search string in the
find command.) There are many much simpler things that are trivial
with ISPF edit and major pains in other editors.
*That's* why I like ispf edit.
/Leonard
>
> Here's a trivial example. Tell me how, using MS Word or Notepad, to
> mark a huge block of text in order to move it or delete it. With
> ISPF edit, you find the first line, put DD or MM, find the last line,
> DD or MM, and you're done. Mouse-cursor marking of large blocks of
> text is very painful. Try marking 10,000 lines this way. Trivial
> in ISPF edit, a nightmare in most other editors as far as I know.
> (I actually know how to do this in emacs, but emacs wears out my
> control-key finger.)
In any GUI editor, you click on the first line/character of the block,
use the scroll bar to scroll down to where the last line of the block
is, press Shift+click and you're done. Mouse-cursor marking is not
painful at all. It's so common, every GUI editor does it the same way.
> How would you do the following with your
> favorite pc or *ix editor (not counting emacs):
>
> X ALL
> F ALL foo word 20 30 .A .B
> C ALL NX bar bletch 65 75
>
> (The string being changed has no relation to the search string in the
> find command.) There are many much simpler things that are trivial
> with ISPF edit and major pains in other editors.
>
> *That's* why I like ispf edit.
This is one of ISPF's strong points. However, it has weak points as
well. For example, try using emulator cut/paste to insert a word or
phrase into an existing line. In a GUI it's trivial. A fixed-width
presentation space can mean plenty of horizontal scrolling activity,
even with large 3270 screens (I use 53x127). GUI's usually autoscroll
and/or wrap text as necessary. They can be resized, can optionally "auto
complete" programming keywords or check spelling as you type. There are
LOTS of things GUI editors do that ISPF doesn't and vice versa.
Personally, my favorite PC editor is called "Ultra Edit"
(http://www.ultraedit.com). It is hands down better than any other PC
editor I've ever used ... and I'm an ISPF bigot! The learning curve is a
lot smaller than emacs.
--
| Edward E. Jaffe | Voice: (310) 338-0400 x318 |
| Mgr., Research & Development | Fax: (310) 338-0801 |
| Phoenix Software International | edj...@phoenixsoftware.com |
| 5200 W. Century Blvd., Suite 800 | USS24J24 at IBMMAIL |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
>I think that there could be non-
>mainframe people who might recognize the power of ISPF edit.
That makes a lot of sense. Outside of the line- and column-oriented
stuff (and who says PC files don't have lines and columns? from the
POV of the user?), there's nothing mainframe-specific about the editor.
>Not if you don't mind having to memorize a half a zillion non-mnemonic
>Control-blah commands, and don't mind the damage that constant use of
>the Control key might be causing.
That's why I like vi and don't like emacs.
>Here's a trivial example. Tell me how, using MS Word or Notepad, to
>mark a huge block of text in order to move it or delete it. With
>ISPF edit, you find the first line, put DD or MM, find the last line,
>DD or MM, and you're done.
In vi:
(find first location)
ma
(scroll, or whatever, to second location)
d`a (to delete into buffer)
(or)
y`a (to copy into buffer)
> X ALL
> F ALL foo word 20 30 .A .B
> C ALL NX bar bletch 65 75
OK, that I can't do in vi as easily.
Though you could write a sed/awk/perl script to do it, it would take
longer to write the script than to do the editing by hand.
But one neat thing about vi is that once you make a change, you can
repeat the change forever with the "." command. So frequently I
will make an edit, then do (<RETURN> .) over and over. Try appending
the same text to each line of the file in ISPF, where the lines all
have different lengths.
Enough from me - this is threatening to get off topic.
- seb
> For very small values of "any" and "every".
>
> I don't *want* the editor to autowrap my code, thank you very much.
Obviously, word wrap is not the most desirable setting for writing code.
It's highly desirable for other things though. Fortunately, this feature
is configurable, even in an "editor" as crude as Notepad.
Shmuel (Seymour J.) Metz
I don't *want* the editor to autowrap my code, thank you very much.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Edward E. Jaffe [SMTP:edj...@PHOENIXSOFTWARE.COM]
> Sent: Thursday, December 07, 2000 3:30 AM
>
> In any GUI editor, you click on the first line/character of the block,
> use the scroll bar to scroll down to where the last line of the block
> is, press Shift+click and you're done. Mouse-cursor marking is not
> painful at all. It's so common, every GUI editor does it the same way.
>
<clipped>
> When I want word wrap in ISPF, I can easily get it with TF. And I
> get it with the margins that I want. If I'm editing text, then I
> probably have imbedded markup and am not likely to want word wrap,
> manual or automatic.
There are two types of word wrap. The first is when new lines are
created in the underlying data by the wrap. This is the only kind of
word wrap ISPF understands (text flow). Horizontal scrolling is still
required to see the data if it is wrapped to margins that exceed the
current display width.
The second type of wrapping is when the text isn't actually wrapped in
the underlying data, but is wrapped for convenience, readability, and
ease of navigation (no horizontal scrolling) to the display window width
(or other margin setting). Word processors generally understand only
this type of wrapping (e.g., Micro$oft Word or Notepad).
Decent GUI editors, such as UltraEdit, understand both.
http://www.planetmvs.com/spfeditor/index.html
Thanks,
Sam Knutson
A good GUI editor, like any good text editor, follows the prime directive of
medicine, "First do no harm." That includes not reformatting text unless
asked to, and not presenting text in a misleading way. If I'm editing source
code, the last thing that I need is for the new lines on the screen to not
match the new lines in the code.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Edward E. Jaffe [SMTP:edj...@PHOENIXSOFTWARE.COM]
> Why would I want an editor to present data in columns that don't match where
> it is storing the data? If I am writing in, e.g., Python, the indentation is
> not only part of the data but a part of the data that affects the semantics.
> As I said before, ISPF lets me do a wrap when I want it without doing it
> being my back and breaking things for me.
I think you've missed the point entirely. What I've been describing in
the area of word wrapping are OPTIONS ... not forced behaviors. You can
do whatever you want, whenever you want. ISPF has fewer options that the
best of the GUI editors in this area. I never said there was anything
wrong with the options ISPF DOES have, it just has fewer of them.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Edward E. Jaffe [SMTP:edj...@PHOENIXSOFTWARE.COM]
This kind of proves my point. It's another magic keystroke that
unless you already know how to do it it's nearly impossible to find
out how. Almost everything that you do in ISPF edit is intuitive,
with easy to remember commands. The same is simply not true of any
other editor.
/Leonard
Mark Hessling recently announce THE 3.1 beta (source only). New features
include added features for ISPF compatibility
.
o Added new prefix commands for all compatibility modes:
+---------------
LC - lowercase line(s)
UC - uppercase line(s)
LCC - lowercase block
UCC - uppercase block
( - shift left column(s) within zone
) - shift left column(s) within zone
(( - shift left column block within zone
)) - shift left column block within zone
Not implemented yet...
O - overlay line(s) - same as OVERLAYBOX (except ISPF mode)
OO - overlay block(s) - same as OVERLAYBOX (except ISPF mode)
+---------------
o Added or modified prefix commands for ISPF compatibility mode:
+---------------
A - after target
B - before target
R - repeat line(s)
RR - repeat block
O - overlay line(s) - (ISPF behaviour)
OO - overlay block(s) - (ISPF behaviour)
COLS - column indicator line
TABS - tabs indicator line
BOUNDS - bounds indicator line
Here's the relevant listings:
READY
PROF PREF(MV41)
READY
ISPSTART CMD(%HELLOW)
ISPSTART ENDED DUE TO ERROR+
USER ABEND CODE 0999 REASON CODE 00013020
2 //BTSO EXEC PGM=IKJEFT01
3 //SYSPROC DD DSN=MV00.@BEB3002.CLIST,DISP=SHR
4 // DD DSN=MV41.@BEB3002.CLIST,DISP=SHR
5 // DD DSN=HC00.SYSPROC,DISP=SHR
6 //ISPPROF DD DSN=MV41.ISPPROF.BATCH,DISP=SHR
7 //ISPPLIB DD DSN=MV00.@BEB3002.ISPPLIB,DISP=SHR
8 //ISPTLIB DD DSN=MV00.@BEB3002.ISPTLIB,DISP=SHR
9 // DD DSN=ISP.SISPTENU,DISP=SHR
10 //ISPMLIB DD DSN=MV00.@BEB3002.ISPMLIB,DISP=SHR
11 //ISPSLIB DD DSN=MV00.@BEB3002.ISPSLIB,DISP=SHR
12 //SYSHELP DD DSN=HC00.@H01.P1.HHELP,DISP=SHR
13 // DD DSN=SYS1.HELP,DISP=SHR
14 //SYSPRINT DD SYSOUT=*
15 //ISPLOG DD SYSOUT=*,
// DCB=(RECFM=VBA,LRECL=125,BLKSIZE=129)
16 //ISPLIST DD SYSOUT=*
17 //SYSTSIN DD *
18 //SYSTSPRT DD SYSOUT=*
19 //SYSUDUMP DD SYSOUT=*
> I am attempting to run an ISPF clist under batch TSO and getting a U0999
> with a reason code of 00013020. I just did a quick search of the ISPF
> messages and codes online book and didn't get a hit.
ISPF Message and Codes does indeed document this abend. Search for
'999'. You will find the description in a section entitled, "Abend Codes
and Information." I'm not sure if the description will help you or not,
but it's there.
Jim Harrison <ji...@QIS.NET> on 26/01/2001 15:28:43
Please respond to ISPF discussion list <ISP...@listserv.nd.edu>
To: ISP...@listserv.nd.edu
cc: (bcc: Ted MacNeil/Operations/ScotiabankGroup)
Subject: Abend U0999 Reason 00013020
I am attempting to run an ISPF clist under batch TSO and getting a U0999
with a reason code of 00013020. I just did a quick search of the ISPF
But I just now went back and looked under 3 and wonder if this could be the
cause:
· An ISPF library allocation does not contain the required ISPF
libraries in its concatenation. For example, the ISPMLIB contains user
product libraries but not ISPF libraries.
I take it this is saying I need *all* the ISP.xxxxxxxx libraries included
whether I'll access them or not? Makes sense now that I think about it -
especially for MLIB & TLIB. I'll have to give that a shot on Monday.
At 04:06 PM 1/26/01 -0500, Ted MacNEIL said:
>What does %HELLOW do?
>