AW: Re: AW: Re: OMVS command history

[Peter Hunkeler]

>>but OMVS has no access to this file.
>What about the history command?



Well, as I wrote, the OMVS command processor has no access to the .sh_history 
file (because it has not been programmed that way). You can of course use the 
histroy shell command. But this is not related to what the OP asked about.


--

Peter Hunkeler



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

AW: Re: JES2 Exit 23

[Peter Hunkeler]

Long time ago (MVS/ESA 3.x in the late 80ies), I wrote JES2 and PSF exits 
to provide (part of) the accounting information as well as some other stuff to 
PSF. It was a combination of JES Exits 3 and 23, as well as PSF exits 1 and 2.
At that time, I did not want to take the burden to extend any JES2 control 
blokc held on the spool, and since it was sufficient, I used some user fields 
in the JCT so save acoounting information in JES2 exit 3.
Later, JES2 exit 23 aquired some storage (getmain) to store this data for PSF 
exits 1 and 2. PSF exit 2 (job end) was in charge of releasing the storage 
after use.

This is from a quick refresh of my memory. Note also that I have not verified 
if there is an easier way nowadays.

I'll send you some code snippets offlist.

 --
Peter Hunkeler


 Von: Lizette Koehler  An:   
IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: JES2 Exit 23 Datum: 31.05.15 07:49


I have not found any definitive info on how to extract the Accounting 
information on a JOB producing output and getting it to the APSUX01/APSUX01P  
exit.

You might want to contact IBM directly via an SR for assistance.

What version of PSF are you running?  Are you using Assembler or C Language?
Have you looked at the IEFJESCT to see what is available in the JES2 
Communications Area?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Saturday, May 30, 2015 5:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 Exit 23
>
> If you are not aware, there is also a JES2 List that might be helpful as well.
> IBMMAIN or JES2 will be good.
>
> To join JES2 - use this URL
> JES2  http://listserv.vt.edu/cgi-bin/wa?A0=jes2-l
>
> Have you looked at the JES2 EXITS manual?  SA22-7534-13   z/OS JES2
> Installation Exits
>
> Lizette
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of Markus Haselbach
> > Sent: Saturday, May 30, 2015 12:38 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: JES2 Exit 23
> >
> > Hallo,
> > I?m for the first time involved with JES2 exits.  The issue is
> > printing with PSF. I have to write accounting information from the Job
> > Card on the Job Header Page. This will be done in PSF Header Exit
> > APSUX01. The question is how to get the information there. I would
> > like to pass the accounting field  by putting it in the  JSPA in JES2
> > Exit 23  HASX23A. Can somebody give me a hint, how to get the Jobcard in
> HASX23A, or an other solution?
> > Best regards
> > Markus Haselbach
> > Credit-Suisse AG
>

--
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: CA-7 question

[Rajesh Kumar]

if jobs are demand , you can see entry mode of job isDEMD .. not
REQ ; Also if job is demand to ca7 it will not waiting for time or date
 request , it will immediately start running.

On Sun, May 31, 2015 at 5:53 PM, Lucas Rosalen 
wrote:

> Are you sure the other jobs are being added by SSCN? Maybe they have/had
> been demanded?
>
> Lucas
> On May 31, 2015 11:19 PM, "Rajesh Kumar"  wrote:
>
> > Hi Tony,
> >
> > I could see span value is *SPAN = 120  and  INCREMENT = 60 from sscan* ;
> > Span=120 is 2 hrs yearly,  (span value must be less than increment)
> >
> >
> >  SPAN=- CHANGES NUMBER OF HOURS SCHEDULE SCAN IS TO LOOK
> > FORWARD, DURING EACH WAKE-UP, FOR JOBS THAT MUST
> > BE ADDED TO THE QUEUES. VALUE MUST BE A NUMBER OF
> > HOURS FROM 1 TO 24. SPAN VALUE MUST NOT BE LESS
> > THAN THE INCR VALUE.
> >
> >
> > Hope now you understood yearly showing of job now
> >
> > Regards,
> > Rajesh
> >
> > On Sun, May 31, 2015 at 4:06 PM, Tony Thigpen  wrote:
> >
> > > I was hoping someone was watching the list today that could help me get
> > > over the hump on this one.
> > >
> > > I know there is some pattern, but it's just not clicking. Some jobs
> seem
> > > to jump in several hours early, while other jump in only 30 minutes
> > before
> > > their time.
> > >
> > > Tony Thigpen
> > >
> > >
> > > Lizette Koehler wrote on 05/31/2015 04:06 PM:
> > >
> > >> I might recommend that, if you have not done so, join the CA Community
> > >> for CA7.  Or open a case with CA.  You may get a much faster response.
> > >>
> > >> Lizette
> > >>
> > >>
> > >>  -Original Message-
> > >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ]
> > >>> On Behalf Of Tony Thigpen
> > >>> Sent: Sunday, May 31, 2015 12:53 PM
> > >>> To: IBM-MAIN@LISTSERV.UA.EDU
> > >>> Subject: CA-7 question
> > >>>
> > >>> I am trying to better understand why jobs show up in the REQ when the
> > >>> show up.
> > >>> For example, I have a job with the following:
> > >>> ID=003   ROLL=D  INDEX=+000
> > >>> SCAL=DOTM=1640  LEADTM=0010  SUBTM=1630  STARTM=1630
> > >>>WEEKLYDAY=SUN
> > >>>
> > >>> And it already in the queue two hours early:
> > >>>LQ,SEQ=JOB
> > >>> XXX REQ 0823 151/1630 151/1630 151/1640  ALL- 003 SSCN  001
> > >>> SLIF-00 REQUEST COMPLETED AT 14:44:59 ON 15.151
> > >>>
> > >>> Yet, other jobs don't seem to appear until almost the time they need
> to
> > >>> run. I
> > >>> think it has to do with the SSCAN values, but nothing seems to be
> > making
> > >>> sense at this point:
> > >>> SSCAN
> > >>>   CURRENT SCHEDULE SCAN VALUES
> > >>>   
> > >>>   SPAN = 120 INCREMENT = 60
> > >>>   QUEUE DWELL = 30  SKELETON RETRY = 0
> > >>>   REPROMPT= 10
> > >>>   LEAD TIME   = 0
> > >>>   STATUS:   REQQ IS ACTIVE  ABR MSGS  = NO
> > >>> RDYQ IS ACTIVE  HOLD JOBS = NO
> > >>>   NEXT SCAN WAKE-UP = 15151 AT 1517
> > >>> NEXT SCAN PERIOD START TIME = 15151 AT 1647
> > >>>
> > >>> --
> > >>> Tony Thigpen
> > >>>
> > >>>
> > >> --
> > >> 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
>

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

Re: Question on 3270 Devices

[Thomas Conley]

On 5/31/2015 11:05 AM, Paul Gilmartin wrote:

On 2015-05-30, at 18:36, J O Skip Robinson wrote:


Sounds a lot like 3290, which was very much an IBM device. Had a large gas 
panel display with orange on black. (Netflix anyone?) Configurable in various 
ways as you describe.
.

An example of how IBM hardware design outpaces its software design.
A couple decades after an IBM terminal supported multiple sessions,
ISPF doesn't support a user's having multiple sessions.

-- gil

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



Incorrect.  ISPF supports multiple user sessions as of z/OS V2R1. 
However, the only 'sploiter Luthy, is z/OSMF.


Regards,
Tom Conley

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

Re: QUESTION ABOUT SPACE ABEND

[Shmuel Metz (Seymour J.)]

In
,
on 05/29/2015
   at 02:51 PM, Steve Coalbran  said:

>What happened to the X37 exit.

As I recall, it was added for the ASB Reader, which did not carry over
to AOS (OS/VS). The exit might still be there, but I doubt that it is
supported.

>I thought it had been incorporated into JES2.

That would have been bizarre. Perhaps you're confusing the exit with
the ASB Reader, which is not needed if you are running ASP, HASP or
JES[123]
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: List of all on-line volumes

[Graham Harris]

MXI is another option.

On 31 May 2015 at 14:19, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In <55673d3b.2020...@vse2pdf.com>, on 05/28/2015
>at 12:07 PM, Tony Thigpen  said:
>
> >Is there simple batch method to get a list of all on-line dasd
> >volumes  without actually coding the volumes in the JCL?
>
> There are several tools available from batch TSO, assuming
> authorization. Are you permitted to use CONSOLE? Also lots of CBTTAPE
> teeols, e.g., PDG86.
>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> 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: CA-7 question

[Lucas Rosalen]

Are you sure the other jobs are being added by SSCN? Maybe they have/had
been demanded?

Lucas
On May 31, 2015 11:19 PM, "Rajesh Kumar"  wrote:

> Hi Tony,
>
> I could see span value is *SPAN = 120  and  INCREMENT = 60 from sscan* ;
> Span=120 is 2 hrs yearly,  (span value must be less than increment)
>
>
>  SPAN=- CHANGES NUMBER OF HOURS SCHEDULE SCAN IS TO LOOK
> FORWARD, DURING EACH WAKE-UP, FOR JOBS THAT MUST
> BE ADDED TO THE QUEUES. VALUE MUST BE A NUMBER OF
> HOURS FROM 1 TO 24. SPAN VALUE MUST NOT BE LESS
> THAN THE INCR VALUE.
>
>
> Hope now you understood yearly showing of job now
>
> Regards,
> Rajesh
>
> On Sun, May 31, 2015 at 4:06 PM, Tony Thigpen  wrote:
>
> > I was hoping someone was watching the list today that could help me get
> > over the hump on this one.
> >
> > I know there is some pattern, but it's just not clicking. Some jobs seem
> > to jump in several hours early, while other jump in only 30 minutes
> before
> > their time.
> >
> > Tony Thigpen
> >
> >
> > Lizette Koehler wrote on 05/31/2015 04:06 PM:
> >
> >> I might recommend that, if you have not done so, join the CA Community
> >> for CA7.  Or open a case with CA.  You may get a much faster response.
> >>
> >> Lizette
> >>
> >>
> >>  -Original Message-
> >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >>> On Behalf Of Tony Thigpen
> >>> Sent: Sunday, May 31, 2015 12:53 PM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: CA-7 question
> >>>
> >>> I am trying to better understand why jobs show up in the REQ when the
> >>> show up.
> >>> For example, I have a job with the following:
> >>> ID=003   ROLL=D  INDEX=+000
> >>> SCAL=DOTM=1640  LEADTM=0010  SUBTM=1630  STARTM=1630
> >>>WEEKLYDAY=SUN
> >>>
> >>> And it already in the queue two hours early:
> >>>LQ,SEQ=JOB
> >>> XXX REQ 0823 151/1630 151/1630 151/1640  ALL- 003 SSCN  001
> >>> SLIF-00 REQUEST COMPLETED AT 14:44:59 ON 15.151
> >>>
> >>> Yet, other jobs don't seem to appear until almost the time they need to
> >>> run. I
> >>> think it has to do with the SSCAN values, but nothing seems to be
> making
> >>> sense at this point:
> >>> SSCAN
> >>>   CURRENT SCHEDULE SCAN VALUES
> >>>   
> >>>   SPAN = 120 INCREMENT = 60
> >>>   QUEUE DWELL = 30  SKELETON RETRY = 0
> >>>   REPROMPT= 10
> >>>   LEAD TIME   = 0
> >>>   STATUS:   REQQ IS ACTIVE  ABR MSGS  = NO
> >>> RDYQ IS ACTIVE  HOLD JOBS = NO
> >>>   NEXT SCAN WAKE-UP = 15151 AT 1517
> >>> NEXT SCAN PERIOD START TIME = 15151 AT 1647
> >>>
> >>> --
> >>> Tony Thigpen
> >>>
> >>>
> >> --
> >> 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

Check out Argecy: Thin Clients, Terminals, and Displays - Insync - IN 3483

[Ed Finnell]

_Argecy: Thin  Clients, Terminals, and Displays - Insync - IN 3483_ 
(http://www.argecy.com/index.php?pfile=IN3483)  
 
Maybe baby!

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

Re: CA-7 question

[Rajesh Kumar]

Hi Tony,

I could see span value is *SPAN = 120  and  INCREMENT = 60 from sscan* ;
Span=120 is 2 hrs yearly,  (span value must be less than increment)


 SPAN=- CHANGES NUMBER OF HOURS SCHEDULE SCAN IS TO LOOK
FORWARD, DURING EACH WAKE-UP, FOR JOBS THAT MUST
BE ADDED TO THE QUEUES. VALUE MUST BE A NUMBER OF
HOURS FROM 1 TO 24. SPAN VALUE MUST NOT BE LESS
THAN THE INCR VALUE.


Hope now you understood yearly showing of job now

Regards,
Rajesh

On Sun, May 31, 2015 at 4:06 PM, Tony Thigpen  wrote:

> I was hoping someone was watching the list today that could help me get
> over the hump on this one.
>
> I know there is some pattern, but it's just not clicking. Some jobs seem
> to jump in several hours early, while other jump in only 30 minutes before
> their time.
>
> Tony Thigpen
>
>
> Lizette Koehler wrote on 05/31/2015 04:06 PM:
>
>> I might recommend that, if you have not done so, join the CA Community
>> for CA7.  Or open a case with CA.  You may get a much faster response.
>>
>> Lizette
>>
>>
>>  -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Tony Thigpen
>>> Sent: Sunday, May 31, 2015 12:53 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: CA-7 question
>>>
>>> I am trying to better understand why jobs show up in the REQ when the
>>> show up.
>>> For example, I have a job with the following:
>>> ID=003   ROLL=D  INDEX=+000
>>> SCAL=DOTM=1640  LEADTM=0010  SUBTM=1630  STARTM=1630
>>>WEEKLYDAY=SUN
>>>
>>> And it already in the queue two hours early:
>>>LQ,SEQ=JOB
>>> XXX REQ 0823 151/1630 151/1630 151/1640  ALL- 003 SSCN  001
>>> SLIF-00 REQUEST COMPLETED AT 14:44:59 ON 15.151
>>>
>>> Yet, other jobs don't seem to appear until almost the time they need to
>>> run. I
>>> think it has to do with the SSCAN values, but nothing seems to be making
>>> sense at this point:
>>> SSCAN
>>>   CURRENT SCHEDULE SCAN VALUES
>>>   
>>>   SPAN = 120 INCREMENT = 60
>>>   QUEUE DWELL = 30  SKELETON RETRY = 0
>>>   REPROMPT= 10
>>>   LEAD TIME   = 0
>>>   STATUS:   REQQ IS ACTIVE  ABR MSGS  = NO
>>> RDYQ IS ACTIVE  HOLD JOBS = NO
>>>   NEXT SCAN WAKE-UP = 15151 AT 1517
>>> NEXT SCAN PERIOD START TIME = 15151 AT 1647
>>>
>>> --
>>> Tony Thigpen
>>>
>>>
>> --
>> 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: CA-7 question

[Tony Thigpen]

I was hoping someone was watching the list today that could help me get 
over the hump on this one.


I know there is some pattern, but it's just not clicking. Some jobs seem 
to jump in several hours early, while other jump in only 30 minutes 
before their time.


Tony Thigpen

Lizette Koehler wrote on 05/31/2015 04:06 PM:

I might recommend that, if you have not done so, join the CA Community for CA7. 
 Or open a case with CA.  You may get a much faster response.

Lizette



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Tony Thigpen
Sent: Sunday, May 31, 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CA-7 question

I am trying to better understand why jobs show up in the REQ when the
show up.
For example, I have a job with the following:
ID=003   ROLL=D  INDEX=+000
SCAL=DOTM=1640  LEADTM=0010  SUBTM=1630  STARTM=1630
   WEEKLYDAY=SUN

And it already in the queue two hours early:
   LQ,SEQ=JOB
XXX REQ 0823 151/1630 151/1630 151/1640  ALL- 003 SSCN  001
SLIF-00 REQUEST COMPLETED AT 14:44:59 ON 15.151

Yet, other jobs don't seem to appear until almost the time they need to run. I
think it has to do with the SSCAN values, but nothing seems to be making
sense at this point:
SSCAN
  CURRENT SCHEDULE SCAN VALUES
  
  SPAN = 120 INCREMENT = 60
  QUEUE DWELL = 30  SKELETON RETRY = 0
  REPROMPT= 10
  LEAD TIME   = 0
  STATUS:   REQQ IS ACTIVE  ABR MSGS  = NO
RDYQ IS ACTIVE  HOLD JOBS = NO
  NEXT SCAN WAKE-UP = 15151 AT 1517
NEXT SCAN PERIOD START TIME = 15151 AT 1647

--
Tony Thigpen



--
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: CA-7 question

[Lizette Koehler]

I might recommend that, if you have not done so, join the CA Community for CA7. 
 Or open a case with CA.  You may get a much faster response.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tony Thigpen
> Sent: Sunday, May 31, 2015 12:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CA-7 question
> 
> I am trying to better understand why jobs show up in the REQ when the
> show up.
> For example, I have a job with the following:
> ID=003   ROLL=D  INDEX=+000
> SCAL=DOTM=1640  LEADTM=0010  SUBTM=1630  STARTM=1630
>   WEEKLYDAY=SUN
> 
> And it already in the queue two hours early:
>   LQ,SEQ=JOB
> XXX REQ 0823 151/1630 151/1630 151/1640  ALL- 003 SSCN  001
> SLIF-00 REQUEST COMPLETED AT 14:44:59 ON 15.151
> 
> Yet, other jobs don't seem to appear until almost the time they need to run. I
> think it has to do with the SSCAN values, but nothing seems to be making
> sense at this point:
> SSCAN
>  CURRENT SCHEDULE SCAN VALUES
>  
>  SPAN = 120 INCREMENT = 60
>  QUEUE DWELL = 30  SKELETON RETRY = 0
>  REPROMPT= 10
>  LEAD TIME   = 0
>  STATUS:   REQQ IS ACTIVE  ABR MSGS  = NO
>RDYQ IS ACTIVE  HOLD JOBS = NO
>  NEXT SCAN WAKE-UP = 15151 AT 1517
>NEXT SCAN PERIOD START TIME = 15151 AT 1647
> 
> --
> Tony Thigpen
> 

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

CA-7 question

[Tony Thigpen]

I am trying to better understand why jobs show up in the REQ when the 
show up.

For example, I have a job with the following:
ID=003   ROLL=D  INDEX=+000
SCAL=DOTM=1640  LEADTM=0010  SUBTM=1630  STARTM=1630
 WEEKLYDAY=SUN

And it already in the queue two hours early:
 LQ,SEQ=JOB
XXX REQ 0823 151/1630 151/1630 151/1640  ALL- 003 SSCN  001
SLIF-00 REQUEST COMPLETED AT 14:44:59 ON 15.151

Yet, other jobs don't seem to appear until almost the time they need to 
run. I think it has to do with the SSCAN values, but nothing seems to be 
making sense at this point:

SSCAN
CURRENT SCHEDULE SCAN VALUES

SPAN = 120 INCREMENT = 60
QUEUE DWELL = 30  SKELETON RETRY = 0
REPROMPT= 10
LEAD TIME   = 0
STATUS:   REQQ IS ACTIVE  ABR MSGS  = NO
  RDYQ IS ACTIVE  HOLD JOBS = NO
NEXT SCAN WAKE-UP = 15151 AT 1517
  NEXT SCAN PERIOD START TIME = 15151 AT 1647

--
Tony Thigpen

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

Re: Notify for XMIT

[Joel Ewing]

On 05/31/2015 09:32 AM, Shmuel Metz (Seymour J.) wrote:
> In <555fe63d.3010...@acm.org>, on 05/22/2015
>at 09:30 PM, Joel Ewing  said:
> 
>> But from APPENDIX A in TSO/E Customization, any command invoked 
>> directly from the TMP that returns a non-0 return code causes the 
>> TMP to end."
> 
> If true, then "10.2  Writing error routines" in the CLIST manual is in
> error, Has anybody tried
> 
>  ERROR +
> DO
>WRITE SEND retu7rned cc &LASTCC
>RETURN  
> END
>  SEND 'message' USER(FOO) NOW
> 
> where the SEND gets a nonzero RC?   
>  
> 
The above CLIST code should presumably work as you expect for
intercepting SEND CLIST "errors" in an Interactive TSO/E, ISPF
environment where TSO is invoked via a TSO logon PROC as IKJEFT01 and
not as IKJEFT1A or IKJEFT1B.  I think the usage of IKJEFT1A/IKJEFT1B is
only possible (certainly only reasonable) in batch TSO, and this was the
context for our discussion with IBM.  The TSO/E CLISTS manual appears to
be written from the standpoint of an Interactive TSO environment where
there is an associated terminal user, which admittedly is the more
common environment for CLIST usage and the environment that has the
fullest capability.

If you look at the referenced TSO/E/Customization Appendix A, you will
find that it explicitly deals with executing the TSO TMP in background
-- i.e. Batch TSO, not interactie TSO.  The rules for batch TSO are
peculiar to that environment -- as obviously you can't expect to do
things from a CLIST in batch TSO that require dynamic decisions by an
interactive user.

The CLIST manual is not in error, just perhaps incomplete in not
explicitly mentioning all limitations when running in a batch TSO
environment or under IKJEFT1A or IKJEFT1B  One could however rationalize
that Since this is not really a limitation of CLISTs but of a specific
TSO/E environment in which it runs, that it makes more sense for the
TSO/E Customization manual and TSO/E User's Manual to lay out this and
other Batch-TSO limitations (which they do) since they are the manuals
that describe how to run TSO in batch, and I suspect they are also the
only manuals that discuss how to use the IKJEFT1A and IKJEFT1B TSO/E
entry points.

I cannot recall years later the historical reason why we started using
IKJEFT1A/IKJEFT1B for Batch TSO rather than IKJEFT01, only that at the
time it seemed like the "logical thing to do".  It didn't bite us until
years later when we migrated to TSO user log files for terminal messages
because of our usage of SEND under a ClIST under batch TSO under
IKJEFJ1A.  From our experience, I'm certain The CLIST ERROR handling
code in the above example would never be reached if the CLIST were
directly executed under IKJEFT1A in batch TSO.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Question on 3270 Devices

[Linda]

No, I had a 3279 SG3 on my desk.  It was also 4 session, but could have only 
one session in the foreground at a time.  The 3290 could display all four 
sessions on screen at the same time. There was a RPQ for the controller to 
support it. All were IBM branded. 

Linda

Sent from my iPhone

> On May 31, 2015, at 10:54 AM, zMan  wrote:
> 
> Right, but this wasn't IBM, and was color (3279). Clearly a 3290 competitor.
> 
>> On Sat, May 30, 2015 at 10:57 PM, Linda  wrote:
>> 
>> We had several of these. IBM 3290. Ours were coax attached to a couple of
>> IBM 3174 Controllers.  Black background, orange character set.
>> 
>> Linda
>> 
>> Sent from my iPhone
>> 
>>> On May 30, 2015, at 5:27 PM, zMan  wrote:
>>> 
>>> OK, this is sorta OT, but related: in the late 1990s I had the pleasure
>> of
>>> working for a while at a customer site. Some of the time I used a
>>> coax-connected device with a large (for the time) screen that could
>> either
>>> support four 3279 sessions at once, or one 3279 session that took the
>> whole
>>> screen (you could switch modes; in single-session mode, you'd then cycle
>>> through the sessions). The single-session mode was great late at night
>> when
>>> very tired.
>>> 
>>> Anyone remember this device? It wasn't IBM.
>>> 
>>> On Fri, May 22, 2015 at 12:40 PM, Pommier, Rex 
>>> wrote:
>>> 
 Probably the last time they sold one.  :-)
 
 Rex
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On
 Behalf Of Charles Mills
 Sent: Friday, May 22, 2015 10:44 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Question on 3270 Devices
 
 "revision date 12/26/2003" ???
 
 Charles
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On
 Behalf Of Mike Schwab
 Sent: Friday, May 22, 2015 8:35 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Question on 3270 Devices
 
 http://www.c-reset.com/terminal.html#IBM
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
 
 The information contained in this message is confidential, protected
>> from
 disclosure and may be legally privileged.  If the reader of this
>> message is
 not the intended recipient or an employee or agent responsible for
 delivering this message to the intended recipient, you are hereby
>> notified
 that any disclosure, distribution, copying, or any action taken or
>> action
 omitted in reliance on it, is strictly prohibited and may be unlawful.
>> If
 you have received this communication in error, please notify us
>> immediately
 by replying to this message and destroy the material in its entirety,
 whether in electronic or hard copy format.  Thank you.
 
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> 
>>> 
>>> 
>>> --
>>> zMan -- "I've got a mainframe and I'm not afraid to use it"
>>> 
>>> --
>>> 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
> 
> 
> 
> -- 
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> 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: Question on 3270 Devices

[Ed Finnell]

Some just like to argue. ISPF has had SPLIT since the beginning and if it  
was on a 3290 device SPLITV.
Typically multiple sessions(VTAM) would be a mix of  
ISPF/CICS/OMEGAMON/BETA42 or RMF. 
 
 
In a message dated 5/31/2015 10:15:05 A.M. Central Daylight Time,  
charl...@mcn.org writes:

One  could argue both ISPF and
the 3290 support "split  screen."


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

Price of OSA Express card

[R.S.]

What is the price of OSA Express5S 1000BaseT (copper) ?
FC 0417 AFAIK.

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: Question on 3270 Devices (3290 Orange Screen!)

[Tony's Outlook via Mozilla]

I loved the 3290, it was the best ever device to design a nicely 
readable report when configured in Cinemascope.  Wish I could emulate it 
on my large monitor.


Always wishing to push a limit I once split my 3290 into 4 screens, each 
having a blinking Omegamon screen running.  I could hear the little gas 
gizmos complaining.


On 5/30/2015 9:57 PM, Linda wrote:

We had several of these. IBM 3290. Ours were coax attached to a couple of IBM 
3174 Controllers.  Black background, orange character set.

Linda

Sent from my iPhone


On May 30, 2015, at 5:27 PM, zMan  wrote:

OK, this is sorta OT, but related: in the late 1990s I had the pleasure of
working for a while at a customer site. Some of the time I used a
coax-connected device with a large (for the time) screen that could either
support four 3279 sessions at once, or one 3279 session that took the whole
screen (you could switch modes; in single-session mode, you'd then cycle
through the sessions). The single-session mode was great late at night when
very tired.

Anyone remember this device? It wasn't IBM.

On Fri, May 22, 2015 at 12:40 PM, Pommier, Rex 
wrote:


Probably the last time they sold one.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, May 22, 2015 10:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on 3270 Devices

"revision date 12/26/2003" ???

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Schwab
Sent: Friday, May 22, 2015 8:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on 3270 Devices

http://www.c-reset.com/terminal.html#IBM

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


The information contained in this message is confidential, protected from
disclosure and may be legally privileged.  If the reader of this message is
not the intended recipient or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any disclosure, distribution, copying, or any action taken or action
omitted in reliance on it, is strictly prohibited and may be unlawful.  If
you have received this communication in error, please notify us immediately
by replying to this message and destroy the material in its entirety,
whether in electronic or hard copy format.  Thank you.


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




--
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
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: Where can a running TSO program get its "terminal name"

[Charles Mills]

The master of the out-of-context quote.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Sunday, May 31, 2015 7:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where can a running TSO program get its "terminal name"

In <03fa01d09573$5a824990$0f86dcb0$@mcn.org>, on 05/23/2015
   at 09:13 AM, Charles Mills  said:

>Sorry to belabor this thread but for the sake of future Googlers felt I 
>needed to say that a global IEABRCX DEFINE is probably a necessary part 
>of this solution.

Not if you use MF=. IEABRCX DEFINE might cause collatral damage, but it's
not my dog.
 

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

Re: LPAR MOBILITY

[Shmuel Metz (Seymour J.)]

In <5540078572993283.wa.wwwdieuyahoo@listserv.ua.edu>, on
05/28/2015
   at 07:31 AM, IBMZOS
<00af65f10fb1-dmarc-requ...@listserv.ua.edu> said:

>Sysplex do the job,

You can switch to a standby server, but you can't migrate an address
space to another LPAR or CEC. Not at all equivalent to what SSI does.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Mysterious U4088-63 from RPTSTG(ON)

[Shmuel Metz (Seymour J.)]

In <0a0e01d0994a$e99c0410$bcd40c30$@mcn.org>, on 05/28/2015
   at 06:33 AM, Charles Mills  said:

>Well, I moved ISAUTH() unchanged to its own assembler module. No
>change in the error. I removed the IEABRCX DEFINE and bingo! It
>works.

My guess is that it doesn't recognize the eye catcher unless there's a
B in front of it. Personally, I consider IEABRCX DEFINE to be a
ticking time bomb and would only use it under duress.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: List of all on-line volumes

[Shmuel Metz (Seymour J.)]

In <55673d3b.2020...@vse2pdf.com>, on 05/28/2015
   at 12:07 PM, Tony Thigpen  said:

>Is there simple batch method to get a list of all on-line dasd
>volumes  without actually coding the volumes in the JCL?

There are several tools available from batch TSO, assuming
authorization. Are you permitted to use CONSOLE? Also lots of CBTTAPE
teeols, e.g., PDG86.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: SMPE MCS construction question re aliases

[Shmuel Metz (Seymour J.)]

In <0bf72eb9d750401a98a23caab0737...@exmbxprd01.ad.ufl.edu>, on
05/28/2015
   at 07:57 PM, "Nims,Alva John (Al)"  said:

>" The ++PROGRAM MCS describes a program element (a pre-built load
>module or a program object). It must immediately precede the load
>module or program object when they are within the SYSMOD.

That would be a good trick. I might believe a GIMZIP compressed
version.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: New Line vs. Line Feed

[Shmuel Metz (Seymour J.)]

In <5567e81c.4040...@vse2pdf.com>, on 05/29/2015
   at 12:16 AM, Tony Thigpen  said:

>1960's ATT pushes for a replacement of ITA2 which the ATA published
>as  ASCII in 1963.

I might believe ASA, through several iterations. I hate overloaded
code points!
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Where can a running TSO program get its "terminal name"

[Shmuel Metz (Seymour J.)]

In <03fa01d09573$5a824990$0f86dcb0$@mcn.org>, on 05/23/2015
   at 09:13 AM, Charles Mills  said:

>Sorry to belabor this thread but for the sake of future Googlers 
>felt I needed to say that a global IEABRCX DEFINE is probably a 
>necessary part of this solution.

Not if you use MF=. IEABRCX DEFINE might cause collatral damage, but
it's not my dog.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: OMVS command history

[Shmuel Metz (Seymour J.)]

In
,
on 05/25/2015
   at 10:55 AM, Ken MacKenzie  said:

>My question, then, is why is my command history kept if I can't use
>it? 

Your question has an assumption contrary to fact. In fact, you *can*
use it. See the history command.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: GENERATED STATEMENT!?

[Shmuel Metz (Seymour J.)]

In
,
on 05/27/2015
   at 04:54 PM, J O Skip Robinson  said:

>//SYMS2 DD  *&IFSYM,SYMBOLS=(EXECSYS,LOGDD2)

>There is no space between asterisk and ampersand. Could that be
>right?

That depends on whether the JES expands the symbols or only the
Converter does.

If the first, it looks not only right but necessary. If the second,
BAD.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Notify for XMIT

[Shmuel Metz (Seymour J.)]

In <555fe63d.3010...@acm.org>, on 05/22/2015
   at 09:30 PM, Joel Ewing  said:

>But from APPENDIX A in TSO/E Customization, any command invoked 
>directly from the TMP that returns a non-0 return code causes the 
>TMP to end."

If true, then "10.2  Writing error routines" in the CLIST manual is in
error, Has anybody tried

 ERROR +
DO
   WRITE SEND retu7rned cc &LASTCC
   RETURN  
END
 SEND 'message' USER(FOO) NOW

where the SEND gets a nonzero RC?   
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Question on 3270 Devices

[zMan]

Right, but this wasn't IBM, and was color (3279). Clearly a 3290 competitor.

On Sat, May 30, 2015 at 10:57 PM, Linda  wrote:

> We had several of these. IBM 3290. Ours were coax attached to a couple of
> IBM 3174 Controllers.  Black background, orange character set.
>
> Linda
>
> Sent from my iPhone
>
> > On May 30, 2015, at 5:27 PM, zMan  wrote:
> >
> > OK, this is sorta OT, but related: in the late 1990s I had the pleasure
> of
> > working for a while at a customer site. Some of the time I used a
> > coax-connected device with a large (for the time) screen that could
> either
> > support four 3279 sessions at once, or one 3279 session that took the
> whole
> > screen (you could switch modes; in single-session mode, you'd then cycle
> > through the sessions). The single-session mode was great late at night
> when
> > very tired.
> >
> > Anyone remember this device? It wasn't IBM.
> >
> > On Fri, May 22, 2015 at 12:40 PM, Pommier, Rex 
> > wrote:
> >
> >> Probably the last time they sold one.  :-)
> >>
> >> Rex
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> >> Behalf Of Charles Mills
> >> Sent: Friday, May 22, 2015 10:44 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Question on 3270 Devices
> >>
> >> "revision date 12/26/2003" ???
> >>
> >> Charles
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> >> Behalf Of Mike Schwab
> >> Sent: Friday, May 22, 2015 8:35 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Question on 3270 Devices
> >>
> >> http://www.c-reset.com/terminal.html#IBM
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >>
> >> The information contained in this message is confidential, protected
> from
> >> disclosure and may be legally privileged.  If the reader of this
> message is
> >> not the intended recipient or an employee or agent responsible for
> >> delivering this message to the intended recipient, you are hereby
> notified
> >> that any disclosure, distribution, copying, or any action taken or
> action
> >> omitted in reliance on it, is strictly prohibited and may be unlawful.
> If
> >> you have received this communication in error, please notify us
> immediately
> >> by replying to this message and destroy the material in its entirety,
> >> whether in electronic or hard copy format.  Thank you.
> >>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> > --
> > zMan -- "I've got a mainframe and I'm not afraid to use it"
> >
> > --
> > 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
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: New Line vs. Line Feed

[Shmuel Metz (Seymour J.)]

In <838271083.1045039.1432870193420.javamail.ya...@mail.yahoo.com>, on
05/29/2015
   at 03:29 AM, "Ze'ev Atlas"
<004b34e7c98a-dmarc-requ...@listserv.ua.edu> said:

>Does anybody know why do we need two characters that seem to do the
>same thing

No, especially since they *don't* do the same thing. A better question
would be why Eunix hijacked the Line Feed instead us using CRLF.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: New Line vs. Line Feed

[Shmuel Metz (Seymour J.)]

In <8215077812992901.wa.paulgboulderaim@listserv.ua.edu>, on
05/29/2015
   at 12:27 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>Using a device-specific hardware command to separate records in a
>general file makes as little sense as Assembler H's use of machine
>carriage control.

Or as Eunix using LF as a record separator.

>A device-neutral convention might have beem
>Record Separator, ASCII 0x1e.

Please inform Ken Thomson.

>IBM clearly violates a standard.

That's not at all clear. What do POSIX et all formally say about the
use of LF-broken ASCII?  -- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: SMPE MCS construction question re aliases

[Shmuel Metz (Seymour J.)]

In <2008381733857340.wa.paulgboulderaim@listserv.ua.edu>, on
05/28/2015
   at 04:10 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>If it's a "real mainframe program", it's delivered in individual
>++MOD elements and linked at customer's site with ++JCLIN.

Or individual ++SRC elements.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: LPAR MOBILITY

[Shmuel Metz (Seymour J.)]

In <0912959236903597.wa.wwwdieuyahoo@listserv.ua.edu>, on
05/28/2015
   at 04:22 AM, IBMZOS
<00af65f10fb1-dmarc-requ...@listserv.ua.edu> said:

>thought Z was at the top of technology.

Z is missing things that IBM developeds on S/360 and S/370. The
cobbler's son is barefoot.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: GENERATED STATEMENT!?

[Shmuel Metz (Seymour J.)]

In <2133628351749565.wa.paulgboulderaim@listserv.ua.edu>, on
05/27/2015
   at 11:37 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>Where does "41 //SYSIN DD *   GENERATED STATEMENT"
>come from? 

It used to come from the R/I, but in MVS I'm not sure if it's C/I or
JES[2|3].

>What does it mean? 

What it's always meant.

>(I had no stray data cards.)

Are you a betting man?

 1. Reproduce the problem with a program that echoes SYSIN

 2. Post the input here

 3. Look at SYSIN form SDSF.
 
 4. Check whether C/I or JES
a. Handles SYSIN
b. Expands symbols.

The most likely explanation is that JES handles SYSIN before the
symbols are substituted. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: AW: Re: OMVS command history

[Shmuel Metz (Seymour J.)]

In , on 05/25/2015
   at 09:27 PM, Peter Hunkeler  said:

>but OMVS has no access to this file.

What about the history command?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Did I really need a CLIST???

[Shmuel Metz (Seymour J.)]

In <20150524072331.5312595.17320.38...@yahoo.ca>, on 05/24/2015
   at 03:23 AM, Ted MacNEIL  said:

>Real programmers don't document code

ITYM real hackers don't document code.

Real men aren't afraid to do something just because some idiotic book
presents a stereotype as mandatory.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Where can a running TSO program get its "terminal name"

[Shmuel Metz (Seymour J.)]

In <03d701d09566$b22a3de0$167eb9a0$@mcn.org>, on 05/23/2015
   at 07:42 AM, Charles Mills  said:

>@Shmuel, "MVS Assembler Services Guide" says

In what context and section? Is the reference to the AMODE24 flag in
the load module or to the actual addressing mode?

The AMODE24 pseudo-op implies RMODEANY, but dynamically setting the
PSW to 24-bit mode does not.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Question on 3270 Devices

[Charles Mills]

It's really TSO that does not, no? If I could just sign onto TSO multiple
times then my desktop with its two 24" monitors would give me all the
multiple sessions I could use.

And I suppose one could argue semantics here. One could argue both ISPF and
the 3290 support "split screen."

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Sunday, May 31, 2015 8:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on 3270 Devices

On 2015-05-30, at 18:36, J O Skip Robinson wrote:

> Sounds a lot like 3290, which was very much an IBM device. Had a large gas
panel display with orange on black. (Netflix anyone?) Configurable in
various ways as you describe. 
> .
An example of how IBM hardware design outpaces its software design.
A couple decades after an IBM terminal supported multiple sessions, ISPF
doesn't support a user's having multiple sessions.

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

Re: Question on 3270 Devices

[Paul Gilmartin]

On 2015-05-30, at 18:36, J O Skip Robinson wrote:

> Sounds a lot like 3290, which was very much an IBM device. Had a large gas 
> panel display with orange on black. (Netflix anyone?) Configurable in various 
> ways as you describe. 
> .
An example of how IBM hardware design outpaces its software design.
A couple decades after an IBM terminal supported multiple sessions,
ISPF doesn't support a user's having multiple sessions.

-- gil

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