Re: Extraneous blanks in SDSF issued command

[Rob Scott]

I don't think that it would be unreasonable for SDSF development to make the 
full screen slash panel aware of wide screen geometry in a future release.


Rob Scott
Rocket Software

On 2 Dec 2020 1:49 am, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
EXTERNAL EMAIL





On Tue, 1 Dec 2020 16:45:46 -0800, Charles Mills wrote:

>I have no idea how all the layers work. My guess is that the SDSF coders
>intended one field, but when it gets turned into 80 columns centered in a >
>80 column wide screen, that ISPF turns it into two fields. As I say, I do
>not know how the various layers there interact with each other.
>
In some cases, such as 3.17, ISPF puts a visible pillarbox around the 80
columns, marking it with  "|".

>See for yourself what I am describing: sign on with a screen wider than 80.
>Go to SDSF and type /+. Hit PF5.
>
Does the behavior differ between 80 columns and wider?  (I think that's
what you're saying.)  Supporting the antique and not the modern is just
bad design.  (How long has the Mod 5 been around?)

>-Original Message-
>From: Seymour J Metz
>Sent: Tuesday, December 1, 2020 4:05 PM
>
>> SDSF thinks it continues
>
>What are you trying to say? Either it is one field or it is not. Where are
>the SF/SFE positions?
>
The TAB key should be telling.  Does TAB move the cursor to the beginning
of that second line (wrong!) or farther, to the next intended field (right).

-- gil

--
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

ICH408I error during Setup and use of the zSecure Visual Server 2.4.0

[Kayhan Tanriverir]

Greetingsall,
I amreceiving the following error when I start up C2RSERVE in zSecure Visual 
Server 2.4.0.  
 ICH408IUSER(C2RSERVE) GROUP(STCGRP  ) NAME(STARTED USER       ) 270     



  /u/c2rserve/server1//bin                                             

 CL(DIRACC  ) FID(D7F2F2D9E2F3092C6C3F006F)                     

 INSUFFICIENT AUTHORITY TO UNLINK                                      

  ACCESSINTENT(-W-)  ACCESS ALLOWED(OTHER      R-X)                     

  EFFECTIVEUID(77)  EFFECTIVE GID(05)              

 STCGRPis started group. C2RSERVE is a member of started group.

 CLASS NAME           

-    

STARTED   C2RS*.* (G) 

 USER ACCESS        

 -- 

STCGRP   READ   

C2RSERVE READ   

IBMUSER  READ   

 I addedSTCGRP and C2RSERVE to the BPX.SUPERUSER profile. I used the following 
commandto

 solvethe problem.

 chmod-R g+rwx /u/c2rserve/server1//bin   

 butdidn’t work.

 Thestatus of directory in omvs is as follows:
 Ö ls -alt/u/c2rserve/server1//bin  lrwxrwxrwx  1 IBMUSER  OMVSGRP       19 Dec 
 1 14:41

 /u/c2rserve/server1//bin–

 >/usr/lpp/c2r/V2R4M0                                                           

Ö                                                                           

 I would greatly appreciate it if you kindly give me somefeedback.





Kayhan TANRIVERIR 



Senior Systems Programmer 



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

Invoking IFASMFDP utility via CALL, LINK, ATTACH ?

[Mike Hochee]

Wondering if anyone has attempted to invoke the SMF IFASMFDP utility (handles 
dumping and clearing of SMF data set logs, digital signature validation, etc.) 
via program invocation using CALL, LINK, or ATTACH?  Some of the dfp utilities 
allow dynamic invocation from a program, and for those some doc is provided, 
however I found no equivalent doc for IFASMFDP. (probably not a good sign) 

Thanks, 
Mike   

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

Re: markup a screen print

[Gadi Ben-Avi]

Newer versions of windows 10 have a tool called Snip & Sketch which allows you 
to capture a screen region and then annotate it.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elaine Beal
Sent: Tuesday, December 1, 2020 7:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: markup a screen print

I want to mark up a screen print and am wanting a way to mark squares, arrows, 
etc.
i use snippet but see only a free form line to use I use Word borders but they 
don't work with an object

Thanks,
Elaine

--
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: Extraneous blanks in SDSF issued command

[Tom Brennan]

And probably dozens more!
Thanks Skip (Vista TN3270 user #1)

On 12/1/2020 5:45 PM, Jesse 1 Robinson wrote:

Wow. I had forgotten about Paste-by-typing! IIRC Tom created that function 
years ago at my request to handle some long since abandoned IBM problem 
management app. Until now I never had a reason to revisit the function.

In my estimation, most of Vista's special copy/paste functions cannot be found 
represented in ANY other emulator.



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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, December 1, 2020 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Extraneous blanks in SDSF issued command

*** EXTERNAL EMAIL - Use caution when opening links or attachments ***

Yes, I use Paste-by-Typing on that panel and it works as desired.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Tuesday, December 1, 2020 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

I purposely don't say Vista emulates any particular real terminal, and there's 
no option to specify you want to look like a 3278 vs. a 3279 or whatever.  That 
helps keep me out of trouble when it comes to details like this :)

But in addition, I took some poetic-license with certain things that bothered 
me about a real terminal.  For example, I seem to remember some programs that 
would initially fill an input area with nulls, and if you moved the cursor out 
to the right and started typing, the host would remove the nulls abd scoot your 
typing to the left.  Not what I wanted, so there's a Vista option (on by 
default) that replaces those nulls to the left with real spaces.  I don't think 
that's involved with this problem though.

There's another option to convert nulls to blanks when sending them to the host 
(off by default), in case anybody needs that.  But that causes enough trouble 
that when you try to set that option in Vista, you get a warning window telling 
you that you probably don't want to do that.

I need to find Skip's original post and see if I can reproduce the error and 
perhaps understand it a bit better, or at least see if it could be an emulator 
issue or not.

I typically use an old PCOMM version I have to determine what a real terminal 
would do, since I'll probably never see another real one except at a museum.  
My theory was the old PCOMM was programmed using logic obtained directly from 
the ROM in a real terminal, maybe even ported.
So I would expect PCOMM to be the gold-standard when any questions come up.

If that SDSF screen is the one I'm thinking of, it's a couple of separate 
fields with a jump to the second line.  If you have a long command in your 
clipboard, you might try the PasteByTyping function which simulates typing each 
character and does the jump.  Menu:
Edit/Paste-Functions/Paste-By-Typing.  But yeah, it might be a stretch to 
expect an emulator to do inserts and deletes as if it was one line.

Oops... Sorry.  Long post.


--
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: Extraneous blanks in SDSF issued command

[Paul Gilmartin]

On Tue, 1 Dec 2020 16:45:46 -0800, Charles Mills wrote:

>I have no idea how all the layers work. My guess is that the SDSF coders
>intended one field, but when it gets turned into 80 columns centered in a >
>80 column wide screen, that ISPF turns it into two fields. As I say, I do
>not know how the various layers there interact with each other.
> 
In some cases, such as 3.17, ISPF puts a visible pillarbox around the 80
columns, marking it with  "|".

>See for yourself what I am describing: sign on with a screen wider than 80.
>Go to SDSF and type /+. Hit PF5.
> 
Does the behavior differ between 80 columns and wider?  (I think that's
what you're saying.)  Supporting the antique and not the modern is just
bad design.  (How long has the Mod 5 been around?)

>-Original Message-
>From: Seymour J Metz
>Sent: Tuesday, December 1, 2020 4:05 PM
>
>> SDSF thinks it continues
>
>What are you trying to say? Either it is one field or it is not. Where are
>the SF/SFE positions?
>
The TAB key should be telling.  Does TAB move the cursor to the beginning
of that second line (wrong!) or farther, to the next intended field (right).

-- gil

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

Re: Extraneous blanks in SDSF issued command

[Jesse 1 Robinson]

Wow. I had forgotten about Paste-by-typing! IIRC Tom created that function 
years ago at my request to handle some long since abandoned IBM problem 
management app. Until now I never had a reason to revisit the function. 

In my estimation, most of Vista's special copy/paste functions cannot be found 
represented in ANY other emulator. 



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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, December 1, 2020 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Extraneous blanks in SDSF issued command

*** EXTERNAL EMAIL - Use caution when opening links or attachments ***

Yes, I use Paste-by-Typing on that panel and it works as desired.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Tuesday, December 1, 2020 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

I purposely don't say Vista emulates any particular real terminal, and there's 
no option to specify you want to look like a 3278 vs. a 3279 or whatever.  That 
helps keep me out of trouble when it comes to details like this :)

But in addition, I took some poetic-license with certain things that bothered 
me about a real terminal.  For example, I seem to remember some programs that 
would initially fill an input area with nulls, and if you moved the cursor out 
to the right and started typing, the host would remove the nulls abd scoot your 
typing to the left.  Not what I wanted, so there's a Vista option (on by 
default) that replaces those nulls to the left with real spaces.  I don't think 
that's involved with this problem though.

There's another option to convert nulls to blanks when sending them to the host 
(off by default), in case anybody needs that.  But that causes enough trouble 
that when you try to set that option in Vista, you get a warning window telling 
you that you probably don't want to do that.

I need to find Skip's original post and see if I can reproduce the error and 
perhaps understand it a bit better, or at least see if it could be an emulator 
issue or not.

I typically use an old PCOMM version I have to determine what a real terminal 
would do, since I'll probably never see another real one except at a museum.  
My theory was the old PCOMM was programmed using logic obtained directly from 
the ROM in a real terminal, maybe even ported.
So I would expect PCOMM to be the gold-standard when any questions come up.

If that SDSF screen is the one I'm thinking of, it's a couple of separate 
fields with a jump to the second line.  If you have a long command in your 
clipboard, you might try the PasteByTyping function which simulates typing each 
character and does the jump.  Menu:
Edit/Paste-Functions/Paste-By-Typing.  But yeah, it might be a stretch to 
expect an emulator to do inserts and deletes as if it was one line.

Oops... Sorry.  Long post.


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

Re: Extraneous blanks in SDSF issued command

[Charles Mills]

I have no idea how all the layers work. My guess is that the SDSF coders
intended one field, but when it gets turned into 80 columns centered in a >
80 column wide screen, that ISPF turns it into two fields. As I say, I do
not know how the various layers there interact with each other.

See for yourself what I am describing: sign on with a screen wider than 80.
Go to SDSF and type /+. Hit PF5.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, December 1, 2020 4:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

> SDSF thinks it continues

What are you trying to say? Either it is one field or it is not. Where are
the SF/SFE positions?

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

Re: Extraneous blanks in SDSF issued command

[Seymour J Metz]

> SDSF thinks it continues

What are you trying to say? Either it is one field or it is not. Where are the 
SF/SFE positions?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Tuesday, December 1, 2020 4:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

Tom Brennan's Vista conforms: if a field runs to the right edge of the screen 
and continues on the next line, then Ins mode pushes characters from one line 
to the next. I recall no relevant experience with any other emulators.

The problem with SDSF /+ is that its "Full Screen" is only 80 characters wide, 
so if your display is wide -- mine is 132 wide FWIW -- the field does not 
really continue. SDSF thinks it continues, and you know it continues, and I 
know it continues, but an emulator has no way of knowing.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 1, 2020 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

On Tue, 1 Dec 2020 17:39:58 +, Seymour J Metz wrote:
>
>"The INS MODE (3275/3277) or ~ (3276/3278/3279) key allows characters to be 
>inserted into a field, while all characters following the point of insertion 
>are shifted to the right."
>
>"If a field is a large one and covers more than one line, and if the situation 
>calls for it, during the insert operation, characters will shift from the end 
>of one line to the beginning of the next."
>
Clear enough.  Thanks.  Citation needed.

So Rob's terminal is nonconforming.  But if that's the modal behavior
among current emulators, it avails suppliers little to count on the
"standard" behavior.  Is it optional?

--
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: Extraneous blanks in SDSF issued command

[Charles Mills]

Yes, I use Paste-by-Typing on that panel and it works as desired.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Tuesday, December 1, 2020 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

I purposely don't say Vista emulates any particular real terminal, and 
there's no option to specify you want to look like a 3278 vs. a 3279 or 
whatever.  That helps keep me out of trouble when it comes to details 
like this :)

But in addition, I took some poetic-license with certain things that 
bothered me about a real terminal.  For example, I seem to remember some 
programs that would initially fill an input area with nulls, and if you 
moved the cursor out to the right and started typing, the host would 
remove the nulls abd scoot your typing to the left.  Not what I wanted, 
so there's a Vista option (on by default) that replaces those nulls to 
the left with real spaces.  I don't think that's involved with this 
problem though.

There's another option to convert nulls to blanks when sending them to 
the host (off by default), in case anybody needs that.  But that causes 
enough trouble that when you try to set that option in Vista, you get a 
warning window telling you that you probably don't want to do that.

I need to find Skip's original post and see if I can reproduce the error 
and perhaps understand it a bit better, or at least see if it could be 
an emulator issue or not.

I typically use an old PCOMM version I have to determine what a real 
terminal would do, since I'll probably never see another real one except 
at a museum.  My theory was the old PCOMM was programmed using logic 
obtained directly from the ROM in a real terminal, maybe even ported. 
So I would expect PCOMM to be the gold-standard when any questions come up.

If that SDSF screen is the one I'm thinking of, it's a couple of 
separate fields with a jump to the second line.  If you have a long 
command in your clipboard, you might try the PasteByTyping function 
which simulates typing each character and does the jump.  Menu: 
Edit/Paste-Functions/Paste-By-Typing.  But yeah, it might be a stretch 
to expect an emulator to do inserts and deletes as if it was one line.

Oops... Sorry.  Long post.

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

Re: Extraneous blanks in SDSF issued command

[Tom Brennan]

I purposely don't say Vista emulates any particular real terminal, and 
there's no option to specify you want to look like a 3278 vs. a 3279 or 
whatever.  That helps keep me out of trouble when it comes to details 
like this :)


But in addition, I took some poetic-license with certain things that 
bothered me about a real terminal.  For example, I seem to remember some 
programs that would initially fill an input area with nulls, and if you 
moved the cursor out to the right and started typing, the host would 
remove the nulls abd scoot your typing to the left.  Not what I wanted, 
so there's a Vista option (on by default) that replaces those nulls to 
the left with real spaces.  I don't think that's involved with this 
problem though.


There's another option to convert nulls to blanks when sending them to 
the host (off by default), in case anybody needs that.  But that causes 
enough trouble that when you try to set that option in Vista, you get a 
warning window telling you that you probably don't want to do that.


I need to find Skip's original post and see if I can reproduce the error 
and perhaps understand it a bit better, or at least see if it could be 
an emulator issue or not.


I typically use an old PCOMM version I have to determine what a real 
terminal would do, since I'll probably never see another real one except 
at a museum.  My theory was the old PCOMM was programmed using logic 
obtained directly from the ROM in a real terminal, maybe even ported. 
So I would expect PCOMM to be the gold-standard when any questions come up.


If that SDSF screen is the one I'm thinking of, it's a couple of 
separate fields with a jump to the second line.  If you have a long 
command in your clipboard, you might try the PasteByTyping function 
which simulates typing each character and does the jump.  Menu: 
Edit/Paste-Functions/Paste-By-Typing.  But yeah, it might be a stretch 
to expect an emulator to do inserts and deletes as if it was one line.


Oops... Sorry.  Long post.

On 12/1/2020 1:50 PM, Charles Mills wrote:

Tom Brennan's Vista conforms: if a field runs to the right edge of the screen 
and continues on the next line, then Ins mode pushes characters from one line 
to the next. I recall no relevant experience with any other emulators.

The problem with SDSF /+ is that its "Full Screen" is only 80 characters wide, 
so if your display is wide -- mine is 132 wide FWIW -- the field does not really 
continue. SDSF thinks it continues, and you know it continues, and I know it continues, 
but an emulator has no way of knowing.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 1, 2020 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

On Tue, 1 Dec 2020 17:39:58 +, Seymour J Metz wrote:


"The INS MODE (3275/3277) or ~ (3276/3278/3279) key allows characters to be inserted 
into a field, while all characters following the point of insertion are shifted to the 
right."

"If a field is a large one and covers more than one line, and if the situation calls 
for it, during the insert operation, characters will shift from the end of one line to 
the beginning of the next."


Clear enough.  Thanks.  Citation needed.

So Rob's terminal is nonconforming.  But if that's the modal behavior
among current emulators, it avails suppliers little to count on the
"standard" behavior.  Is it optional?

--
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

Salesforce is buying workplace messaging app Slack for $27.7 billion in its biggest deal ever

[Lizette Koehler]

https://www.businessinsider.com/salesforce-slack-acquisition-merger-deal-202
0-11

 

 

The deal is Salesforce's largest acquisition ever and represents a more
aggressive foray into office communication technology at a time when remote
work has made chat and collaboration tools more essential than ever

 

 

Lizette

 


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

Re: Extraneous blanks in SDSF issued command

[Charles Mills]

Tom Brennan's Vista conforms: if a field runs to the right edge of the screen 
and continues on the next line, then Ins mode pushes characters from one line 
to the next. I recall no relevant experience with any other emulators.

The problem with SDSF /+ is that its "Full Screen" is only 80 characters wide, 
so if your display is wide -- mine is 132 wide FWIW -- the field does not 
really continue. SDSF thinks it continues, and you know it continues, and I 
know it continues, but an emulator has no way of knowing.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 1, 2020 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

On Tue, 1 Dec 2020 17:39:58 +, Seymour J Metz wrote:
>
>"The INS MODE (3275/3277) or ~ (3276/3278/3279) key allows characters to be 
>inserted into a field, while all characters following the point of insertion 
>are shifted to the right."  
>
>"If a field is a large one and covers more than one line, and if the situation 
>calls for it, during the insert operation, characters will shift from the end 
>of one line to the beginning of the next."
> 
Clear enough.  Thanks.  Citation needed.

So Rob's terminal is nonconforming.  But if that's the modal behavior
among current emulators, it avails suppliers little to count on the
"standard" behavior.  Is it optional?

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

Re: Is there a JES2 command to submit a job?

[Charles Mills]

> Could you split it on multiple lines

I am neither a console nor a JES command expert but I think the problem is that 
the maximum length console command from any source is 126 (?) characters. Does 
JES perhaps support some sort of continuation convention external to MVS 
console restrictions (as SLIP does)? I don't know.

I am not sure if the RDR PROC that I have is IBM-original or if someone 
modified it for their own purposes, but it says 

//IEFRDERDDUNIT=TAPE,LABEL=(,NL),VOL=SER=JES2IN,DISP=OLD, 
// DCB=(RECFM=F,BLKSIZE=80,LRECL=80)  

Not the most helpful defaults.

BTW, SDSF does not insert blanks. The OP in that thread had the blanks right 
there in front of him on the panel. SDSF just honored what was typed. Might it 
be user-helpful were SDSF to *strip* blanks at the end of a continued line? 
Quite possibly.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 1, 2020 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there a JES2 command to submit a job?

On Tue, 1 Dec 2020 11:52:48 -0800, Charles Mills wrote:
>
>My reading was that there was no MODIFY involved with $SUBMIT. It *is* a JES2 
>command as I read things. It is I think the answer to what I was looking for 
>with my OP "is there a JES2 command to submit a job?" I chose to go with the 
>RDR proc because it looked a little simpler.
>
I misled myself, perhaps by the description of "$T (modify) SUBMITLIB" in:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0za100/ch1jes2_24_disk.htm

And:  
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.hasa400/submitlib1.htm
These concatenations can contain any combination of partitioned data sets 
(PDSs) or file system paths. 
"paths"!?  Yaaay!  It's almost as if they forgot the 20th Century.

But, (Yaaay!): ... The concatenation supports any format PDS (LRECL and RECFM)
that can be used to pass JCL into input processing.

... files in the path with 1-8 character uppercase file names that conform 
to
standard PDS member names ...
I suspect that restriction can be circumvented with symlinks.

Are the lexical rules for JES commands the same as for "standard PDS
member names"?

>Footnote: Little did I know. What a PITA RDR turned out to be, at least on my 
>particular LPAR. I had to override RECFM, LRECL, BLKSIZE, UNIT, VOL and DISP 
>(as well as DSN of course). That made my $TA command too long for the MVS 
>console. I had to shorten my DSN and member names a little to get it to fit.
> 
IEBGENER is so nice!  It honors the label attributes!

Could you split it on multiple lines provided that your (emulated) terminal
doesn't insert extraneous blanks?

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

Re: Calculating duration from subtracting TOD clocks

[Steff Gladstone]

Thank you!

On Thu, 26 Nov 2020 at 23:32, Charles Mills  wrote:

> I should add that I have code that does exactly what you are talking
> about. That's why I am familiar with the problem.
>
> // Keep track of time in [particular function]
> Platform::STCKF();
>
> // call [a particular function here]
>
> // Keep track of time in [particular function]
> Platform::STCKF();
> timeInFunction += (TOD - EntryTOD);
>
> Platform::STCKF() is an inline call to __stckf() which is a hardware STCKF.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Thursday, November 26, 2020 1:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Calculating duration from subtracting TOD clocks
>
> @Steff, I totally "get" your question. You have some function that is
> called repeatedly and you want to know the total elapsed time spent in that
> function. So you want to get a TOD on the way in, subtract it from a TOD on
> the way out, and then sum those differences. Makes perfect sense. And you
> are worried that you are factoring in 12 irrelevant bits that may add up
> over time.
>
> You are (mostly) mathematically correct but if it were me I would not
> worry about it. First of all, I suspect that in modern machines the actual
> clock resolution is a lot finer than 1 usecond, so not all of those 12 bits
> are irrelevant. Second, I suspect much of the error would cancel itself
> out. But yes, I don't really know, and worst case, you could be off by
> almost a usecond on every difference, and after a few thousand sums it
> might amount to something.
>
> What to do? Well, you could just AND off those 12 bits. Little harm,
> although on a box with finer resolution you are throwing away information
> that might be relevant. How about just using STCKF; it has two benefits:
> first, as the name implies, it is FASTER than an STCK in certain
> circumstances -- much faster (the exact circumstances are irrelevant to
> this discussion, but trust me, it is a LOT faster sometimes). And second,
> the PoOp says "For STORE CLOCK FAST, when the value of a running clock is
> stored, bits to the right of the rightmost bit that is incremented are
> stored as zeros."
>
> QED
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steff Gladstone
> Sent: Thursday, November 26, 2020 7:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Calculating duration from subtracting TOD clocks
>
> Could someone answer 4gb's 11-year-late question?
>
> On Tuesday, April 17, 2018 at 11:53:30 PM UTC+3, 4gb...@gmail.com wrote:
>
> > On Monday, September 3, 2007 at 4:38:21 PM UTC-7, Ludmila Koganer wrote:
> > > Hi,
> > > I need to subtract two TOD times to find elapsed time. Currently I
> convert
> > > the two TOD times with STCKCONV and determine the elaped time
> individually,
> > > and then compute the difference. This works. However I thought I could
> > > optimize the conversion, a little bit and I was wondering why not
> subtract the
> > > two TOD times to begin with.
> > >
> > > As I understand TOD time is the number of mic seconds elapsed since
> midnight
> > > of 1900-01-01. So when I subtract one TOD value from another the
> duration
> > > must be in micro seconds.
>
> > I'm 11 years late. Shouldn't you clear the low order 12 bits of each TOD
> value before adding or subtracting them? Those low order bits are not
> fractions of a microsecond, so including them in the math can produce up to
> a micro second error. If you add a series of TOD values without clearing
> the low bits that can add up to real money.
>
> --
> 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: RMM tape movement to vault

[Joe Testa]

Jake,

RMM uses a Vital Record Specification (VRS) to control tape movement from one 
location to another.  A VRS can be defined with many attributes to select the 
criteria for moving tapes.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Monday, November 30, 2020 2:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RMM tape movement to vault

Hello

I apologise for the dummy question as I am new to Tape DFRMM

We have a job which searches the RMM catalog for the tape to be in drive and 
vault.

Some questions popped out in my mind. How does RMM decides that a particular 
tape has to be moved to VAULT and how does it know that tape must be moved from 
VAULT to Tape drive .

Please help me to understand how this works out .

Regards
Jake

--
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: Is there a JES2 command to submit a job?

[Paul Gilmartin]

On Tue, 1 Dec 2020 11:52:48 -0800, Charles Mills wrote:
>
>My reading was that there was no MODIFY involved with $SUBMIT. It *is* a JES2 
>command as I read things. It is I think the answer to what I was looking for 
>with my OP "is there a JES2 command to submit a job?" I chose to go with the 
>RDR proc because it looked a little simpler.
>
I misled myself, perhaps by the description of "$T (modify) SUBMITLIB" in:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0za100/ch1jes2_24_disk.htm

And:  
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.hasa400/submitlib1.htm
These concatenations can contain any combination of partitioned data sets 
(PDSs) or file system paths. 
"paths"!?  Yaaay!  It's almost as if they forgot the 20th Century.

But, (Yaaay!): ... The concatenation supports any format PDS (LRECL and RECFM)
that can be used to pass JCL into input processing.

... files in the path with 1-8 character uppercase file names that conform 
to
standard PDS member names ...
I suspect that restriction can be circumvented with symlinks.

Are the lexical rules for JES commands the same as for "standard PDS
member names"?

>Footnote: Little did I know. What a PITA RDR turned out to be, at least on my 
>particular LPAR. I had to override RECFM, LRECL, BLKSIZE, UNIT, VOL and DISP 
>(as well as DSN of course). That made my $TA command too long for the MVS 
>console. I had to shorten my DSN and member names a little to get it to fit.
> 
IEBGENER is so nice!  It honors the label attributes!

Could you split it on multiple lines provided that your (emulated) terminal
doesn't insert extraneous blanks?

-- gil

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

Re: Is there a JES2 command to submit a job?

[Steve Smith]

The provided RDR proc is now useful only as an example.  Note it uses
IEBEDIT, the poor utility that gets no respect.

When a started task name is IEFPROC, DD IEFRDER has some special properties
that allow unit, and (I think) volume to be specified as positional
operands, and any DD keywords on the start command are applied to it.
Note: my recollection, not guaranteed to be definitive.

Forty some-odd years ago, as an operator I submitted job streams with a RDR
proc that replaced SYSUT1 with DSN=PROD.JCL().  Quite simple to "S
XRDR,JOB=jobyyy", and I'd think fairly obvious.  You can embellish that to
your taste, but I like simple & easy-to-remember-&-type commands.

I'll repeat that the // SCHEDULE statement is pretty handy.  And if you
activate the full JOB GROUP facility, you might not need any other job
control system.

sas

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

Re: Is there a JES2 command to submit a job?

[Charles Mills]

> IBM has already generously done that chore for IEBGENER.

Touché. How about "any program capable of copying xSAM to xSAM plus INTRDR"? 
IEBGENER is a good shorthand.

My reading was that there was no MODIFY involved with $SUBMIT. It *is* a JES2 
command as I read things. It is I think the answer to what I was looking for 
with my OP "is there a JES2 command to submit a job?" I chose to go with the 
RDR proc because it looked a little simpler.

Footnote: Little did I know. What a PITA RDR turned out to be, at least on my 
particular LPAR. I had to override RECFM, LRECL, BLKSIZE, UNIT, VOL and DISP 
(as well as DSN of course). That made my $TA command too long for the MVS 
console. I had to shorten my DSN and member names a little to get it to fit.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 1, 2020 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there a JES2 command to submit a job?

On Tue, 1 Dec 2020 10:43:14 -0800, Charles Mills wrote:

>Well, they're different environments for one thing. FTP FILETYPE=JES is 
>wonderful, but it does not run as a JES2 command. Ditto TSO and ISPF SUBMIT.
>
>To nitpick, IEBGENER is irrelevant, right? SYSOUT INTRDR is the key; you can 
>get there equally well from IEBGENER, REXX, or a COBOL program.
> 
Someone would need to code that Rexx or COBOL.  IBM has already
generously done that chore for IEBGENER.

Apparently: 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0za100/ch1jes2_24_disk.htm
the disk writer does nothing but wait until a MODIFY command tells
it to SUBMIT a job.  Is that better than SUBMITting immediately and
quitting?

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

Re: Is there a JES2 command to submit a job?

[Paul Gilmartin]

On Tue, 1 Dec 2020 10:43:14 -0800, Charles Mills wrote:

>Well, they're different environments for one thing. FTP FILETYPE=JES is 
>wonderful, but it does not run as a JES2 command. Ditto TSO and ISPF SUBMIT.
>
>To nitpick, IEBGENER is irrelevant, right? SYSOUT INTRDR is the key; you can 
>get there equally well from IEBGENER, REXX, or a COBOL program.
> 
Someone would need to code that Rexx or COBOL.  IBM has already
generously done that chore for IEBGENER.

Apparently: 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0za100/ch1jes2_24_disk.htm
the disk writer does nothing but wait until a MODIFY command tells
it to SUBMIT a job.  Is that better than SUBMITting immediately and
quitting?

I'd need to look further to learn the constraints on the RECFM and
LRECL of the member to submit from or the submitted JCL.   I'm
so optimistic as to expect there are none beyond those imposed by
JES2 itself.

"Job security is based on the source of the $SUBMIT command."
I don't know what "source" means here, nor whose employment
prospects are affected.

The IEBGENER proc could have been written by customers many
releases ago:
//STEP EXEC PGM=IEBGENER
//SYSUT1  DD  DDNAME=IEFRDER  /* I'm guessing.  */
//SYSUT2  DD  SYSOUT=(,INTRDR)
//* ...

-- gil

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

Re: Extraneous blanks in SDSF issued command

[Seymour J Metz]

GA27-2742  for the second quote.

Entry Assist is all or nothing; if it's on then Ins mode causes inserted text 
to replace the blanks without shifting the non-blank text to the right. I don't 
recall whether it leaves a separating blank.


--
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: Tuesday, December 1, 2020 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

On Tue, 1 Dec 2020 17:39:58 +, Seymour J Metz wrote:
>
>"The INS MODE (3275/3277) or ~ (3276/3278/3279) key allows characters to be 
>inserted into a field, while all characters following the point of insertion 
>are shifted to the right."
>
>"If a field is a large one and covers more than one line, and if the situation 
>calls for it, during the insert operation, characters will shift from the end 
>of one line to the beginning of the next."
>
Clear enough.  Thanks.  Citation needed.

So Rob's terminal is nonconforming.  But if that's the modal behavior
among current emulators, it avails suppliers little to count on the
"standard" behavior.  Is it optional?

>IBM had a ... sensible idea on some mode[l]s; if you enabled Entry Assist then 
>you could treat blanks as nulls for purposes of insert.
>
All blanks?  Trailing blanks?  Respect column alignment like ISPF Edit Change?

-- 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: Is there a JES2 command to submit a job?

[Charles Mills]

Well, they're different environments for one thing. FTP FILETYPE=JES is 
wonderful, but it does not run as a JES2 command. Ditto TSO and ISPF SUBMIT.

To nitpick, IEBGENER is irrelevant, right? SYSOUT INTRDR is the key; you can 
get there equally well from IEBGENER, REXX, or a COBOL program.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 1, 2020 8:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there a JES2 command to submit a job?

On Sun, 29 Nov 2020 18:47:56 -0800, Ed Jaffe wrote:
>
>IBM added many JES3 features to JES2 over the last decade in an effort
>to make JES2 more palatable to JES3 customers. One of those features was
>support for a "disk reader" -- something JES3 had for as long as anyone
>can remember.
>
>The purpose of a disk reader is to have a JES command submit a job from
>a PDS[E] member. If you're on the right release of JES2, you might have
>this feature.
>
What credentials does this require?  On which userID does that submitted
job run?  Must the JCL member contain a password?

How is this preferable to OMVS submit, TSO SUBMIT, ISPF SUBMIT,
IEBGENER INTRDR, or FTP FILETYPE=JES?  (Only) the last two are not
restricted by the archaic FB-80 restriction.  What about disk reader?

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

Re: Extraneous blanks in SDSF issued command

[Paul Gilmartin]

On Tue, 1 Dec 2020 17:39:58 +, Seymour J Metz wrote:
>
>"The INS MODE (3275/3277) or ~ (3276/3278/3279) key allows characters to be 
>inserted into a field, while all characters following the point of insertion 
>are shifted to the right."  
>
>"If a field is a large one and covers more than one line, and if the situation 
>calls for it, during the insert operation, characters will shift from the end 
>of one line to the beginning of the next."
> 
Clear enough.  Thanks.  Citation needed.

So Rob's terminal is nonconforming.  But if that's the modal behavior
among current emulators, it avails suppliers little to count on the
"standard" behavior.  Is it optional?

>IBM had a ... sensible idea on some mode[l]s; if you enabled Entry Assist then 
>you could treat blanks as nulls for purposes of insert.
>
All blanks?  Trailing blanks?  Respect column alignment like ISPF Edit Change?

-- gil

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

Re: Extraneous blanks in SDSF issued command

[Seymour J Metz]

> Is a written specification available,

"The INS MODE (3275/3277) or ~ (3276/3278/3279) key allows characters to be 
inserted into a field, while all characters following the point of insertion 
are shifted to the right."  

"If a field is a large one and covers more than one line, and if the situation 
calls for it, during the insert operation, characters will shift from the end 
of one line to the beginning of the next."

> Does IBM market "a real 3270" nowadays?

I doubt it. But what do HOD and PCCOMM do?

> Many emulators replace NULs followed by a non-null charater (sic)
> with spaces in the transmitted data stream,

That's what I call a Molly Malone:

 She died of a faever
 From which none could save her

IBM had a more sensible idea on some modes; if you enabled Entry Assist then 
you could treat blanks as nulls for purposes of insert.


--
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: Tuesday, December 1, 2020 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

On Tue, 1 Dec 2020 11:34:54 +, Seymour J Metz wrote:

>Does anybody have a real 3270 they can test it on? FWIW, it works on TSPF, and 
>Tritus was extremely serious about compatability.
>
Is a written specification available, as opposed to empirical?
Does IBM market "a real 3270" nowadays?

Many emulators replace NULs followed by a non-null charater with
spaces in the transmitted data stream, claiming WYSIWIG as a
motivation.  This is often configurable in Settings.

At times I've relied on the original behavior.  To append characters
to a line it may be faster to "<-" around the right edge of the screen,
type there, and rely on collapse of the intervening NULs.

Long ago I used a 3270 lookalike, hardware, which optionally
displayed NULs visibly distinguished  from spaces.


>
>From: Rob Scott
>Sent: Tuesday, December 1, 2020 3:50 AM
>
>I have just tested the ISRTSO (and ISRTSOA) panels in ISPF 7.2 and they both 
>fail the first issue (SKIP) when shown in a POPUP (this is expected).
>
>They both fail the second issue (INSERT/EOF) no matter if POPUP or not.

-- 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: markup a screen print

[Lionel B Dyck]

My preference for markup is to use SnagIt from techsmith.com.  It is extremely 
robust and also can be used to create videos from either screen captures or 
from the live screen (with audio).  I've been successful everywhere I've worked 
in getting my employer to order a copy for my work PC (and I have my own 
personal copy as well).

Check it out - the free trial will snag you 

(I'm not an employee or in any other way affiliated with techsmith)

Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elaine Beal
Sent: Tuesday, December 1, 2020 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: markup a screen print

I want to mark up a screen print and am wanting a way to mark squares, arrows, 
etc.
i use snippet but see only a free form line to use I use Word borders but they 
don't work with an object

Thanks,
Elaine

--
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: markup a screen print

[Joe Monk]

MS Paint

joe

On Tue, Dec 1, 2020 at 11:03 AM Elaine Beal  wrote:

> I want to mark up a screen print and am wanting a way to mark squares,
> arrows, etc.
> i use snippet but see only a free form line to use
> I use Word borders but they don't work with an object
>
> Thanks,
> Elaine
>
> --
> 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: markup a screen print

[Seymour J Metz]

Will gimp do what you need?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Elaine Beal [elaine.b...@gxs.com]
Sent: Tuesday, December 1, 2020 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: markup a screen print

I want to mark up a screen print and am wanting a way to mark squares, arrows, 
etc.
i use snippet but see only a free form line to use
I use Word borders but they don't work with an object

Thanks,
Elaine

--
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

markup a screen print

[Elaine Beal]

I want to mark up a screen print and am wanting a way to mark squares, arrows, 
etc.
i use snippet but see only a free form line to use
I use Word borders but they don't work with an object

Thanks,
Elaine

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

Re: Is there a JES2 command to submit a job?

[Paul Gilmartin]

On Sun, 29 Nov 2020 18:47:56 -0800, Ed Jaffe wrote:
>
>IBM added many JES3 features to JES2 over the last decade in an effort
>to make JES2 more palatable to JES3 customers. One of those features was
>support for a "disk reader" -- something JES3 had for as long as anyone
>can remember.
>
>The purpose of a disk reader is to have a JES command submit a job from
>a PDS[E] member. If you're on the right release of JES2, you might have
>this feature.
>
What credentials does this require?  On which userID does that submitted
job run?  Must the JCL member contain a password?

How is this preferable to OMVS submit, TSO SUBMIT, ISPF SUBMIT,
IEBGENER INTRDR, or FTP FILETYPE=JES?  (Only) the last two are not
restricted by the archaic FB-80 restriction.  What about disk reader?

-- gil

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

Re: Extraneous blanks in SDSF issued command

[Paul Gilmartin]

On Tue, 1 Dec 2020 11:34:54 +, Seymour J Metz wrote:

>Does anybody have a real 3270 they can test it on? FWIW, it works on TSPF, and 
>Tritus was extremely serious about compatability.
>
Is a written specification available, as opposed to empirical?
Does IBM market "a real 3270" nowadays?

Many emulators replace NULs followed by a non-null charater with
spaces in the transmitted data stream, claiming WYSIWIG as a
motivation.  This is often configurable in Settings.

At times I've relied on the original behavior.  To append characters
to a line it may be faster to "<-" around the right edge of the screen,
type there, and rely on collapse of the intervening NULs.

Long ago I used a 3270 lookalike, hardware, which optionally
displayed NULs visibly distinguished  from spaces.


>
>From: Rob Scott 
>Sent: Tuesday, December 1, 2020 3:50 AM
>
>I have just tested the ISRTSO (and ISRTSOA) panels in ISPF 7.2 and they both 
>fail the first issue (SKIP) when shown in a POPUP (this is expected).
>
>They both fail the second issue (INSERT/EOF) no matter if POPUP or not.

-- gil

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

Re: Extraneous blanks in SDSF issued command

[Seymour J Metz]

Does anybody have a real 3270 they can test it on? FWIW, it works on TSPF, and 
Tritus was extremely serious about compatability.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Rob 
Scott [rsc...@rocketsoftware.com]
Sent: Tuesday, December 1, 2020 3:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

I have just tested the ISRTSO (and ISRTSOA) panels in ISPF 7.2 and they both 
fail the first issue (SKIP) when shown in a POPUP (this is expected).

They both fail the second issue (INSERT/EOF) no matter if POPUP or not.

I think this leaves a wide-screen only solution the most likely method of 
solving this, which is not ideal but better than nothing.

Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 30 November 2020 22:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

EXTERNAL EMAIL



On Tue, 1 Dec 2020 08:14:06 +1100, Attila Fogarasi wrote:

>SKIP(ON) is the ISPF panel field attribute that causes automatic skip to
>next field when the cursor reaches the end of a field (SKIP(OFF) is the
>default). I'm not 100% sure about your second question (insert spanning
>
Not needed.

>fields) but AFAIK insert is limited to a single field (it certainly was in
>the original hardware). Normally a scrollable area would be used instead
>of 2 fields when they are actually 1 field logically. Not sure that all
>3270 emulators work correctly with the fancier data streams (or rather,
>I've run into lots of problems doing this).
>
IBM seems determined to inconvenience users of wide screens. The
"ISPF Command Shell panel (ISRTSO)" (see illustration):
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.f54u200/chap9.htm

... provides a single field covering 3 lines on an 80-column screen so
insertion simply works up to the size of the field.

This answers Rob's concern; Yes, it's possible.

On a wider screen, the panel is formatted in a "pillarbox" (GIYF) and
insertion works only within a single line. When I ranted about this
(on ISPF-L?) experts advised me, "Oh you need ISRTSOA":
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.f54pc00/isppc115.htm

... Hmmm. Configuration option; not available to mere mortal users.
But I copied ISRTSOA into my private ISPPLIB and renamed it. All
better. ISPF 3.17 suffers a similar misdesign in its entry panel with
wide screens for a poor reason.


>On Tue, Dec 1, 2020 at 7:29 AM Rob Scott wrote:
>
>> In your example, assuming that the input field spans two lines :
>>
>> (1) When the user starts to type on the first line and gets to the end of
>> the input field in the line, is the input skipped to the next line?
>>
>> (2) If there is existing data on the second line and the user attempts to
>> insert data on the first line, does the data on the second line shift to
>> accommodate the inserted bytes.
>>
>> If both the above are satisfied, then I would doff my cap to you and
>> implement a solution based on that in the next release.

-- gil

--
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

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

Re: Auto Reply on SDSF Console

[Jeremy Nicoll]

On Mon, 30 Nov 2020, at 23:21, Steve Horein wrote:
> This guy gets it - "TOKEN" is useful, so long as the vendor doesn't change
> the message layout.

You say that, but wait until someone runs a job whose name includes any 
of those volser values, and needs some other volume mounted.

Running a rexx exec is an overhead, but it can do more sophisticated 
checks of what's being asked for.  


> On Mon, Nov 30, 2020 at 11:47 AM Cieri, Anthony <
> 02d7f4ec1fff-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > You could try something like this:
> >
> > IF (LABEL:IEF455D) MSGID = 'IEF455D' & TEXT(1) = REPLYID .
> > & (TEXT = .'SP5145'. | TEXT = .'SP5146'. | TEXT = .'SP5147'. |
> > TEXT = .'SP5149'.)
> > THEN EXEC(CMD('MVS REPLY ' REPLYID ',NO')
> >  ROUTE(ONE AUTO1)) NETLOG(Y);
> >
> > With everything coded in the MAT, there is no need for a rexx!!!

-- 
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: Extraneous blanks in SDSF issued command

[Rob Scott]

I have just tested the ISRTSO (and ISRTSOA) panels in ISPF 7.2 and they both 
fail the first issue (SKIP) when shown in a POPUP (this is expected).

They both fail the second issue (INSERT/EOF) no matter if POPUP or not.

I think this leaves a wide-screen only solution the most likely method of 
solving this, which is not ideal but better than nothing.

Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 30 November 2020 22:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks in SDSF issued command

EXTERNAL EMAIL



On Tue, 1 Dec 2020 08:14:06 +1100, Attila Fogarasi wrote:

>SKIP(ON) is the ISPF panel field attribute that causes automatic skip to
>next field when the cursor reaches the end of a field (SKIP(OFF) is the
>default). I'm not 100% sure about your second question (insert spanning
>
Not needed.

>fields) but AFAIK insert is limited to a single field (it certainly was in
>the original hardware). Normally a scrollable area would be used instead
>of 2 fields when they are actually 1 field logically. Not sure that all
>3270 emulators work correctly with the fancier data streams (or rather,
>I've run into lots of problems doing this).
>
IBM seems determined to inconvenience users of wide screens. The
"ISPF Command Shell panel (ISRTSO)" (see illustration):
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.f54u200/chap9.htm

... provides a single field covering 3 lines on an 80-column screen so
insertion simply works up to the size of the field.

This answers Rob's concern; Yes, it's possible.

On a wider screen, the panel is formatted in a "pillarbox" (GIYF) and
insertion works only within a single line. When I ranted about this
(on ISPF-L?) experts advised me, "Oh you need ISRTSOA":
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.f54pc00/isppc115.htm

... Hmmm. Configuration option; not available to mere mortal users.
But I copied ISRTSOA into my private ISPPLIB and renamed it. All
better. ISPF 3.17 suffers a similar misdesign in its entry panel with
wide screens for a poor reason.


>On Tue, Dec 1, 2020 at 7:29 AM Rob Scott wrote:
>
>> In your example, assuming that the input field spans two lines :
>>
>> (1) When the user starts to type on the first line and gets to the end of
>> the input field in the line, is the input skipped to the next line?
>>
>> (2) If there is existing data on the second line and the user attempts to
>> insert data on the first line, does the data on the second line shift to
>> accommodate the inserted bytes.
>>
>> If both the above are satisfied, then I would doff my cap to you and
>> implement a solution based on that in the next release.

-- gil

--
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