Re: Findproc CBTTAPE ?

[Brian Westerman]

Here is a Clist that does what you are looking for.  You have to update the 
lines with the proclibs on them to have your proclib names (add more or remove 
some if you don't have the same number of proclibs)

i.e. you need these two lines ofr each proclib:

SET &HINUM = &HINUM + 1
SET &PROC&HINUM = name .of.proclib

.  It allows you to search all of your proclibs and optionally ispf edit or 
browse the member if found;

I.E> TSO FINDPROC JES2 EDIT (will search the proclibs, find the JES2 proc, and 
put you in ispf edit on it).

The order in the clist should match your exact order in your JES2 proceedure.

 /* FINDPROC TSO/E CLIST */
 /* FINDPROC IS A CLIST THAT WILL SEARCH THE JES PROCLIB */
 /* CONCATENATION FINDING A TARGET MEMBER. SEVERAL OPTIONS ARE   */
 /* AVAILABLE:   */
 /*  */
 /*  WRITE  - SHOW LIBRARY NAME AS IT IS SEARCHED*/
 /*  */
 /*  QUIT   - QUIT AFTER FIRST OCCURANCE OF TARGET   */
 /*  */
 /*  EDIT   - EDIT THE TARGET MEMBER WHEN FOUND  */
 /*  */
 /*  BROWSE - BROWSE THE TARGET MEMBER WHEN FOUND*/
 /*  */
 /*  THIS CLIST MUST BE UPDATED WITH THE PROCLIBS IN THE ORDER JES   */
 /*  SEARCHES THEM. THIS IS USUALLY IN THE JES2 PROC OR THE JES3 */
 /*  INISH DECK. */
 /*  */
 /*  */
 /* SYNTAX: FINDPROC PROCNAME {WRITE QUIT EDIT BROWSE}   */
 /*  */
 //
   
PROC 1 MBR WRITE  QUIT EDIT BROWSE 
 SET &PROC = PROC  
SET &HINUM = &HINUM + 1
SET &PROC&HINUM = PZOS.PROCLIB 
SET &HINUM = &HINUM + 1
SET &PROC&HINUM = SYS1.MLTIPROC
SET &HINUM = &HINUM + 1
SET &PROC&HINUM = SYS1.PROCLIB 
SET &HINUM = &HINUM + 1
SET &PROC&HINUM = SYS1.IBM.PROCLIB 
SET &HINUM = &HINUM + 1
SET &PROC&HINUM = UTLS.PD.PROCLIB  
SET &HINUM = &HINUM + 1
SET &PROC&HINUM = CSBP.PD.PROCLIB  
SET &HINUM = &HINUM + 1
SET &PROC&HINUM = CSBP.PD.VENDPROC 
SET &HINUM = &HINUM + 1 
SET &PROC&HINUM = SAPD.PD.PROCLIB   
WRITE SEARCHING SYSTEM PROCLIBS FOR PROC: &MBR  
LOOP: + 
SET &CTR = &CTR + 1 
IF &CTR > &HINUM THEN GOTO OUT  
SET &LIB = &&PROC&CTR   
IF &WRITE =  WRITE THEN DO  
WRITE  SEARCHING '&LIB' 
END 
IF &SYSDSN('&LIB(&MBR)') = OK THEN DO   
IF &WRITE = EDIT |  +   
   &QUIT  = EDIT |  +   
   &BROWSE = EDIT |  +  
   &EDIT  = EDIT THEN  DO   
ISPEXEC EDIT DATASET('&LIB(&MBR)')  
GOTO CHECKXIT   
END 
IF &WRITE = BROWSE | +  
   &QUIT  = BROWSE | +  
   &BROWSE = BROWSE | + 
   &EDIT  = BROWSE THEN DO  

Re: Findproc CBTTAPE ?

[Lizette Koehler]

That works so long as the proc you are looking for is in the JES2 environment.  
If your users are using JCLLIB statements, then you need to find all of the 
JCLLIB Datasets and scan for those.

You can do the same thing.

JCLLIB statements with all of your proclibs.  Then try the JCL process.

Caveat.  If the proc member is in multiple libraries, you will only find the 
first occurrence.

I will use the 3.14 option in batch and concatenate all of my proclibs and then 
SEARCH for what I am looking for.  Tends to find those in all libraries rather 
than just the first one.


If you have a strong naming convention, like SYS1.**.PROCLIB bring those up in 
3.4 and then SRCHFOR or MEMBER on the command line.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Anthony Thompson
> Sent: Monday, July 08, 2019 8:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Findproc CBTTAPE ?
> 
> I just run JCL invoking the proc with a deliberate JCL error.
> 
> Like so:
> 
> //
> /*ROUTE XEQ <--- to pick up any certain system's standard proclib
> order of search
> //FINDPROC EXEC ,JCLERROR=YES
> 
> The IEFC001I message in the JESYSMSG dataset tells where the procedure was
> found.
> 
> IEFC001I PROCEDURE 
> 
> You don't need some clever utility from CBT or any other source to figure
> this out.
> 
> Ant.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Jake Anderson
> Sent: Tuesday, 9 July 2019 1:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Findproc CBTTAPE ?
> 
> Hi
> 
> Is there a file within CBTTAPE to find a specific proc among the JES2 procs ?
> 
> I am looking through but still didn't get a one yet .
> 
> Any pointers would be appreciated
> 
> Jake.
> 

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

Re: Findproc CBTTAPE ?

[Anthony Thompson]

I just run JCL invoking the proc with a deliberate JCL error.

Like so: 

//
/*ROUTE XEQ <--- to pick up any certain system's standard proclib 
order of search
//FINDPROC EXEC ,JCLERROR=YES

The IEFC001I message in the JESYSMSG dataset tells where the procedure was 
found.

IEFC001I PROCEDURE 

You don't need some clever utility from CBT or any other source to figure this 
out.

Ant.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Tuesday, 9 July 2019 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Findproc CBTTAPE ?

Hi

Is there a file within CBTTAPE to find a specific proc among the JES2 procs ?

I am looking through but still didn't get a one yet .

Any pointers would be appreciated

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

Findproc CBTTAPE ?

[Jake Anderson]

Hi

Is there a file within CBTTAPE to find a specific proc among the JES2 procs
?

I am looking through but still didn't get a one yet .

Any pointers would be appreciated

Jake.

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

Unresolved external references when trying to link DLL app

[Joseph Reichman]

Hi

 

I am getting a number of unresolved external references when trying to link
my DLL app

 

There are  CEE (language environment ) modules and C library functions like
fopen

 

However the most troubling is the C function I exported I included the side
deck which has my exported function

 

Strangely thought even tough I included a pragma map to leave the name as it
appended _FPC

 

Here  is he generated side deck

-

IMPORT CODE64,'TESTDLL','openadata__FPc'   

 

Here is my DLL code

#pragma export(openadata)

#pragma map(__ceetest,"CEETEST")

#pragma linkage(CEETEST,FETCHABLE)  

#pragma map(opnadata,"openadata")   

void openadata(char *filename)  

{   

 __ceetest();   

 FILE *fp = fopen("DD:TESTFILE","r"); 

 

} 

 

 

>From my understanding the sidedeck would be concatenated to IEWL SYSLIN and
the DLLLIB (a pdse) would be concatenated IEWL SYSLIB

 

 

 

 

 


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

Re: Determine TSO USERMAX?

[Steve Horein]

Thanks again Tony, and I tend to agree that going the storage route in this
case is a dead end.
I've been trying to avoid command/response when possible for a few reasons:

   - Command response timeouts (a storage call when possible should be
   immediate)
   - Key message ID avoidance ("D TS" result was updated from IEE114I to
   CNZ4105I in z/OS 2.3)
   - Log noise ("D TS" produces a 3 line MLWTO)
   - Extra/Undesired information returned (I'm interested explicitly in
   USERMAX value)

If I can "quietly" get the exact information desired with less overhead, I
feel like I improved my world in a little way :-)
... and if I can't, that's ok too.


On Mon, Jul 8, 2019 at 5:30 PM Cieri, Anthony  wrote:

>
> I think that the TCAST is located in Fetch protected storage. You
> would need authorized code to even read it. I believe that is why Netview
> rexx gets a null values.
>
> Is there a problem with issuing commands???
>
> In my opinion, it would be easier to Pipe a 'D TS' command to MVS
> and parse the reply for the usermax value!!!
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Horein
> Sent: Monday, July 08, 2019 5:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determine TSO USERMAX?
>
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders. ***
> ]]
>
>
> Thanks Tony!
> My intent is to merely interrogate to ensure someone hadn't left an
> undesired value after a change window.
> Traveling down the path of CVT > TCAST > TCASUMAX using Rexx storage calls
> (via NetView) yields a null value.
> The old doc mentioned TCAST was located in "System common area", but
> perhaps it moved to private?
> Anyway, I appreciate the help!
>
>
> On Mon, Jul 8, 2019 at 3:56 PM Cieri, Anthony  wrote:
>
> >
> > Are you looking to set the usermax to an appropriate value via
> > automation, or simply trying to determine the current value??
> >
> > In the CVT there is a pointer to the TCAST, CVTTCASP is at offset
> > 1012 (x'3F4') in the CVT.
> >
> > I believe that TCASUMAX is a 2 byte field at offset 6 in the
> > TCAST. I think that you will need to be authorized to display it!!!
> >
> > Hth
> > Tony
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Steve Horein
> > Sent: Monday, July 08, 2019 3:52 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Determine TSO USERMAX?
> >
> > [[ SEI WARNING *** This email was sent from an external source. Do not
> > open attachments or click on links from unknown or suspicious senders.
> ***
> > ]]
> >
> >
> > Hi!
> > In an effort to improve automation, I am looking for a method to
> determine
> > TSO USERMAX other than issuing console commands. Blowing the dust off old
> > documentation, "z/OS V1R10.0 Comm Svr: SNA Data Areas Volume 1", I found
> > "TCASUMAX" in "Terminal Control Address Space Table" (TCAST). Neat. This
> > would seem to fill the need. However, it appears SNA Data Areas are no
> > longer being published for modern z operating systems to verify this
> > information is still available. Does anyone know of a way to get this
> > information?
> >
> > --
> > 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: Determine TSO USERMAX?

[Cieri, Anthony]

I think that the TCAST is located in Fetch protected storage. You would 
need authorized code to even read it. I believe that is why Netview rexx gets a 
null values.

Is there a problem with issuing commands???

In my opinion, it would be easier to Pipe a 'D TS' command to MVS and 
parse the reply for the usermax value!!!



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Horein
Sent: Monday, July 08, 2019 5:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determine TSO USERMAX?

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


Thanks Tony!
My intent is to merely interrogate to ensure someone hadn't left an
undesired value after a change window.
Traveling down the path of CVT > TCAST > TCASUMAX using Rexx storage calls
(via NetView) yields a null value.
The old doc mentioned TCAST was located in "System common area", but
perhaps it moved to private?
Anyway, I appreciate the help!


On Mon, Jul 8, 2019 at 3:56 PM Cieri, Anthony  wrote:

>
> Are you looking to set the usermax to an appropriate value via
> automation, or simply trying to determine the current value??
>
> In the CVT there is a pointer to the TCAST, CVTTCASP is at offset
> 1012 (x'3F4') in the CVT.
>
> I believe that TCASUMAX is a 2 byte field at offset 6 in the
> TCAST. I think that you will need to be authorized to display it!!!
>
> Hth
> Tony
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Horein
> Sent: Monday, July 08, 2019 3:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Determine TSO USERMAX?
>
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders. ***
> ]]
>
>
> Hi!
> In an effort to improve automation, I am looking for a method to determine
> TSO USERMAX other than issuing console commands. Blowing the dust off old
> documentation, "z/OS V1R10.0 Comm Svr: SNA Data Areas Volume 1", I found
> "TCASUMAX" in "Terminal Control Address Space Table" (TCAST). Neat. This
> would seem to fill the need. However, it appears SNA Data Areas are no
> longer being published for modern z operating systems to verify this
> information is still available. Does anyone know of a way to get this
> information?
>
> --
> 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: Load Module lookup ? (resolved)

[Lionel B Dyck]

The issue was the program I was calling itself called another using a process 
that precluded it being in a LIBDEF ISPLLIB ☹

Thanks to all for your suggestions


Lionel B. Dyck <
Website: http://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 
ITschak Mugzach
Sent: Monday, July 8, 2019 3:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Load Module lookup ?

if it is a foreground task, use ISRDDN with MEMEBER xxx  or even better LOAD 
xxx to find where the loadmodule is taken from.

ITschak

On Mon, Jul 8, 2019 at 11:03 PM Seymour J Metz  wrote:

> Do you specify NEWAPPL? PASSLIB? What is the failure mode if not an S806?
>
> I wouldn't expect address ISPEXEC to work with a LIBDEF'd library 
> unless the code was called with SELECT CMD(xxx). I don't recall the 
> details, but combining LIBDEF for ISPLLIB with SELECT PGM(xxx) can be a bit 
> tricky.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Lionel B Dyck 
> Sent: Monday, July 8, 2019 2:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Load Module lookup ?
>
> I have some code that calls a load module.  In my unit test, both 
> online and batch, with a hard coded DD for ISPLLIB, the call to the 
> program works using both Address LINKMVS and Address ISPEXEC 'Select 
> PGM(xxx)'. When I change to use a LIBDEF both address Linkmvs and 
> address ispexec select fail but do not report an 806.
>
>
>
> The only thing that actually works without the hardcoded DD is to call 
> 'loadlib(lmod)' which I'm very reluctant to do but it's the only thing 
> I can for now.
>
>
>
> I have a feeling this is something trivial that I'm just overlooking.
>
>
>
> Advice please.
>
>
>
>
>
> Lionel B. Dyck <
> Website:  <
> http://secure-web.cisco.com/1qTuIlTf1nXvUomUHQT2zApFG_ycbaGzCbFDaC6bti
> ekdAZe4nHD5PTAZz6G3SE_XFk9z6__883XpJF-_ltKIQ0tbETvSyWp1YoltsSrBMLpP3BY
> nXVBKgT9adxNYDxeq7mtgbPYlZ2e45eJZvvGhbmOc84qGgaH6bUNLucYH9SOedSskHSbID
> 5rZpvS1JtOBWSKa2S4aBSQrlWFJhcuXffTn1cvwNBKc0t3VEA3QGmX_SmQHTDFc5zGCe1H
> -1_NMjcVOcuXbg4ANDeqD7MVvR50_cxs1OntwFZySPAbXDZ_T3jx2zIB1yXhB5hzL35_zK
> 2Kpf2tNLIGwf4ks25l7GRKqm6g4dWUgu-4NOVzzNMpaCV4B9yXSrQWYrr35t_P3WLoQ1pI
> t4CmfXVSSpOKVOBhIs_u6TncTp0pfalUlW4p1B6ccW2Ez3-0C4evhX9Qc/http%3A%2F%2
> Fwww.lbdsoftware.com%2F>
>
> http://secure-web.cisco.com/1bPHxGiKvMfoTCluc1O03HuyW0i1mkswU6CybQQMMk
> IFwMsy9YmEB8FZzFDjQM-1V9eWdYuDHeVoBoXsrBx72pP7YYo-bn94Lhal41Pfjht5so8g
> c681gcGtNW36IUas_1Nx_hs_nHrtFvpV8mmRzMhpS62fRoNA9ypwtXVDUrOc_N5Ibjkvu8
> gMSL0qOp-e8XF1Yz81-VJcbtsJke-VqPdpdEWsedyEnlzbKTJXDxQAR-DW0D91aERZ00Sw
> ZFKPBbVX46F0sT-0qtlpRoJfFy07aNbJrenyqFDANrb3Q8K9f3hAkDVQ2Hc8hK2ohr31Nn
> 4czd2phNWUXE3UGpzovpshIIyvUQ3OdXAZN0jHeIlX0bXrOxSewF8M42T-HGOt_eoyYuHW
> K_f9R9afDzweFKy46XCtb0U1cSchNnrtTg_-Rwcd2oo
> !
>  nPuThscSw1saHL/http%3A%2F%2Fwww.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is 
> what you are, reputation merely what others think you are." - John 
> Wooden
>
>
>
>
> --
> 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
>


--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for 
Legacy **|  *

--
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: Determine TSO USERMAX?

[Steve Horein]

Thanks Tony!
My intent is to merely interrogate to ensure someone hadn't left an
undesired value after a change window.
Traveling down the path of CVT > TCAST > TCASUMAX using Rexx storage calls
(via NetView) yields a null value.
The old doc mentioned TCAST was located in "System common area", but
perhaps it moved to private?
Anyway, I appreciate the help!


On Mon, Jul 8, 2019 at 3:56 PM Cieri, Anthony  wrote:

>
> Are you looking to set the usermax to an appropriate value via
> automation, or simply trying to determine the current value??
>
> In the CVT there is a pointer to the TCAST, CVTTCASP is at offset
> 1012 (x'3F4') in the CVT.
>
> I believe that TCASUMAX is a 2 byte field at offset 6 in the
> TCAST. I think that you will need to be authorized to display it!!!
>
> Hth
> Tony
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Horein
> Sent: Monday, July 08, 2019 3:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Determine TSO USERMAX?
>
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders. ***
> ]]
>
>
> Hi!
> In an effort to improve automation, I am looking for a method to determine
> TSO USERMAX other than issuing console commands. Blowing the dust off old
> documentation, "z/OS V1R10.0 Comm Svr: SNA Data Areas Volume 1", I found
> "TCASUMAX" in "Terminal Control Address Space Table" (TCAST). Neat. This
> would seem to fill the need. However, it appears SNA Data Areas are no
> longer being published for modern z operating systems to verify this
> information is still available. Does anyone know of a way to get this
> information?
>
> --
> 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: Determine TSO USERMAX?

[Cieri, Anthony]

Are you looking to set the usermax to an appropriate value via 
automation, or simply trying to determine the current value??

In the CVT there is a pointer to the TCAST, CVTTCASP is at offset 1012 
(x'3F4') in the CVT.

I believe that TCASUMAX is a 2 byte field at offset 6 in the TCAST. I 
think that you will need to be authorized to display it!!!

Hth
Tony


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Horein
Sent: Monday, July 08, 2019 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Determine TSO USERMAX?

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


Hi!
In an effort to improve automation, I am looking for a method to determine
TSO USERMAX other than issuing console commands. Blowing the dust off old
documentation, "z/OS V1R10.0 Comm Svr: SNA Data Areas Volume 1", I found
"TCASUMAX" in "Terminal Control Address Space Table" (TCAST). Neat. This
would seem to fill the need. However, it appears SNA Data Areas are no
longer being published for modern z operating systems to verify this
information is still available. Does anyone know of a way to get this
information?

--
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: JCL to include data

[Mark Pace]

Oh how I got led down a path today.

Guy told me a lot of stuff, but not everything. I didn't ask him the right
questions, ASSuMEing, he knew what he was doing.  He was trying to insert
VB records in the JCL, and he was out of space in the PDS.

But I think I did learn something from you guys concerning the question I
asked as opposed to what the problem actually was.

On Mon, Jul 8, 2019 at 3:33 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 8 Jul 2019 14:02:20 -0500, Elardus Engelbrecht wrote:
> >...
> >??? Please explain that. Do you mean, you want to add the members as an
> input into that JCL? Why not just concatenate them using some DD statements?
> > ...
> >Why not use a [concatenated] DD refering to the source of that data in
> that flat file / PDs / members of that PDS?
> >
> Me, too.  But this thread inspired me to RTFM, where I see:
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ikjc500/ikj2l2_SUBMIT_command_operands.htm
> Note [brightly highlighed]
> All characters in the job stream are converted to uppercase
> before being processed.
>
> WTF!?  Does that mean that if I SUBMIT a job containing:
> //SYSUT1  DD  *
> This is Mixed Case text.
> The effect is the same as:
> //SYSUT1  DD  *
> THIS IS MIXED CASE TEXT.
>
> I don't remember it that way, but I confess I can't remember having
> tried it.  Lately I've submitted only via FTP or copy to INTRDR.  But
> is a clarification RCF in order?
>
> I'd advocate RFEs for a
> oSUBMIT FROMDDNAME(...) option
> oRemoving the Fixed-80 restriction, relaxed for JES2 circa z/OS 1.5
>  and for JESZ3 far earlier, but lingering in TSO/ISPF submit.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: JCL to include data

[Paul Gilmartin]

On Mon, 8 Jul 2019 14:33:14 -0500, Paul Gilmartin wrote:
>   ...
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ikjc500/ikj2l2_SUBMIT_command_operands.htm
>Note [brightly highlighed]
>All characters in the job stream are converted to uppercase
>before being processed.
>
>WTF!?  Does that mean that if I SUBMIT a job containing:
>//SYSUT1  DD  *
>This is Mixed Case text.
>The effect is the same as:
>//SYSUT1  DD  *
>THIS IS MIXED CASE TEXT.
>
I've received an off-list clarification (thanks) that that applies only to
"SUBMIT *",  as opposed to "SUBMIT dsn".  The behavior is yet increasingly
oppressively archaic in that "SUBMIT *" precludes reference to, for example
UNIX files with mixed case names.  Where's ASIS when you need it?

>I'd advocate RFEs for a
>oSUBMIT FROMDDNAME(...) option
>oRemoving the Fixed-80 restriction, relaxed for JES2 circa z/OS 1.5
> and for JESZ3 far earlier, but lingering in TSO/ISPF submit.
o ASIS in many more places; even global to the TSO session.

-- gil

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

Re: Load Module lookup ?

[ITschak Mugzach]

if it is a foreground task, use ISRDDN with MEMEBER xxx  or even better
LOAD xxx to find where the loadmodule is taken from.

ITschak

On Mon, Jul 8, 2019 at 11:03 PM Seymour J Metz  wrote:

> Do you specify NEWAPPL? PASSLIB? What is the failure mode if not an S806?
>
> I wouldn't expect address ISPEXEC to work with a LIBDEF'd library unless
> the code was called with SELECT CMD(xxx). I don't recall the details, but
> combining LIBDEF for ISPLLIB with SELECT PGM(xxx) can be a bit tricky.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Lionel B Dyck 
> Sent: Monday, July 8, 2019 2:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Load Module lookup ?
>
> I have some code that calls a load module.  In my unit test, both online
> and
> batch, with a hard coded DD for ISPLLIB, the call to the program works
> using
> both Address LINKMVS and Address ISPEXEC 'Select PGM(xxx)'. When I change
> to
> use a LIBDEF both address Linkmvs and address ispexec select fail but do
> not
> report an 806.
>
>
>
> The only thing that actually works without the hardcoded DD is to call
> 'loadlib(lmod)' which I'm very reluctant to do but it's the only thing I
> can
> for now.
>
>
>
> I have a feeling this is something trivial that I'm just overlooking.
>
>
>
> Advice please.
>
>
>
>
>
> Lionel B. Dyck <
> Website:  <
> http://secure-web.cisco.com/1qTuIlTf1nXvUomUHQT2zApFG_ycbaGzCbFDaC6btiekdAZe4nHD5PTAZz6G3SE_XFk9z6__883XpJF-_ltKIQ0tbETvSyWp1YoltsSrBMLpP3BYnXVBKgT9adxNYDxeq7mtgbPYlZ2e45eJZvvGhbmOc84qGgaH6bUNLucYH9SOedSskHSbID5rZpvS1JtOBWSKa2S4aBSQrlWFJhcuXffTn1cvwNBKc0t3VEA3QGmX_SmQHTDFc5zGCe1H-1_NMjcVOcuXbg4ANDeqD7MVvR50_cxs1OntwFZySPAbXDZ_T3jx2zIB1yXhB5hzL35_zK2Kpf2tNLIGwf4ks25l7GRKqm6g4dWUgu-4NOVzzNMpaCV4B9yXSrQWYrr35t_P3WLoQ1pIt4CmfXVSSpOKVOBhIs_u6TncTp0pfalUlW4p1B6ccW2Ez3-0C4evhX9Qc/http%3A%2F%2Fwww.lbdsoftware.com%2F>
>
> http://secure-web.cisco.com/1bPHxGiKvMfoTCluc1O03HuyW0i1mkswU6CybQQMMkIFwMsy9YmEB8FZzFDjQM-1V9eWdYuDHeVoBoXsrBx72pP7YYo-bn94Lhal41Pfjht5so8gc681gcGtNW36IUas_1Nx_hs_nHrtFvpV8mmRzMhpS62fRoNA9ypwtXVDUrOc_N5Ibjkvu8gMSL0qOp-e8XF1Yz81-VJcbtsJke-VqPdpdEWsedyEnlzbKTJXDxQAR-DW0D91aERZ00SwZFKPBbVX46F0sT-0qtlpRoJfFy07aNbJrenyqFDANrb3Q8K9f3hAkDVQ2Hc8hK2ohr31Nn4czd2phNWUXE3UGpzovpshIIyvUQ3OdXAZN0jHeIlX0bXrOxSewF8M42T-HGOt_eoyYuHWK_f9R9afDzweFKy46XCtb0U1cSchNnrtTg_-Rwcd2oo
> !
>  nPuThscSw1saHL/http%3A%2F%2Fwww.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
>
>
>
> --
> 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
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: Load Module lookup ?

[Seymour J Metz]

Do you specify NEWAPPL? PASSLIB? What is the failure mode if not an S806?

I wouldn't expect address ISPEXEC to work with a LIBDEF'd library unless the 
code was called with SELECT CMD(xxx). I don't recall the details, but combining 
LIBDEF for ISPLLIB with SELECT PGM(xxx) can be a bit tricky.


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


From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Monday, July 8, 2019 2:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Load Module lookup ?

I have some code that calls a load module.  In my unit test, both online and
batch, with a hard coded DD for ISPLLIB, the call to the program works using
both Address LINKMVS and Address ISPEXEC 'Select PGM(xxx)'. When I change to
use a LIBDEF both address Linkmvs and address ispexec select fail but do not
report an 806.



The only thing that actually works without the hardcoded DD is to call
'loadlib(lmod)' which I'm very reluctant to do but it's the only thing I can
for now.



I have a feeling this is something trivial that I'm just overlooking.



Advice please.





Lionel B. Dyck <
Website:  

 
http://secure-web.cisco.com/1bPHxGiKvMfoTCluc1O03HuyW0i1mkswU6CybQQMMkIFwMsy9YmEB8FZzFDjQM-1V9eWdYuDHeVoBoXsrBx72pP7YYo-bn94Lhal41Pfjht5so8gc681gcGtNW36IUas_1Nx_hs_nHrtFvpV8mmRzMhpS62fRoNA9ypwtXVDUrOc_N5Ibjkvu8gMSL0qOp-e8XF1Yz81-VJcbtsJke-VqPdpdEWsedyEnlzbKTJXDxQAR-DW0D91aERZ00SwZFKPBbVX46F0sT-0qtlpRoJfFy07aNbJrenyqFDANrb3Q8K9f3hAkDVQ2Hc8hK2ohr31Nn4czd2phNWUXE3UGpzovpshIIyvUQ3OdXAZN0jHeIlX0bXrOxSewF8M42T-HGOt_eoyYuHWK_f9R9afDzweFKy46XCtb0U1cSchNnrtTg_-Rwcd2oo!
 nPuThscSw1saHL/http%3A%2F%2Fwww.lbdsoftware.com

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




--
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: JCL to include data

[Paul Gilmartin]

On Mon, 8 Jul 2019 19:42:58 +, Seymour J Metz wrote:

>Does the OP need to do SUBMIT? 
>
This feels like a case where the user is throwing his influence around
and invoking middle management's support against an "unresponsive"
support staff's refusal to accommodate the user's way.

>Do you have a business case for removing the brain-dead FB80 restriction in 
>SUBMIT?
>
Not specifically, but there must have been one for the much harder task of
removing that restriction from JES2.

It's a pity that "brain-dead" isn't per se a business case.  Putrefaction?

-- gil

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

Determine TSO USERMAX?

[Steve Horein]

Hi!
In an effort to improve automation, I am looking for a method to determine
TSO USERMAX other than issuing console commands. Blowing the dust off old
documentation, "z/OS V1R10.0 Comm Svr: SNA Data Areas Volume 1", I found
"TCASUMAX" in "Terminal Control Address Space Table" (TCAST). Neat. This
would seem to fill the need. However, it appears SNA Data Areas are no
longer being published for modern z operating systems to verify this
information is still available. Does anyone know of a way to get this
information?

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

Re: JCL to include data

[Seymour J Metz]

Does the OP need to do SUBMIT? 

Do you have a business case for removing the brain-dead FB80 restriction in 
SUBMIT?


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, July 8, 2019 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL to include data

On Mon, 8 Jul 2019 14:02:20 -0500, Elardus Engelbrecht wrote:
>...
>??? Please explain that. Do you mean, you want to add the members as an input 
>into that JCL? Why not just concatenate them using some DD statements?
> ...
>Why not use a [concatenated] DD refering to the source of that data in that 
>flat file / PDs / members of that PDS?
>
Me, too.  But this thread inspired me to RTFM, where I see:

https://secure-web.cisco.com/1GlMdtzvEKP3x9RqXA8s_aHoLb9YfYKrWBmjvTHgf5RzAfVFTkz1Z-ed3kk0u3oc93-HJYBc0K9WpdRW16K4JQUWKaZq9XGUQGbbz5wRMR-O-uW0ZdvdLnKeFRToho8EBEQZVpQGhWRr35wBOtCciDnwvrbGf4S_yhMV7GD19EwgA43ktd7MzLCvkLLtxU0-xhfptTaA0B-jH-p4ProHXmVTlWmIyrMpz6VJaih3830obRNcAuO0VfJetpvumiXVj_f8O9YCpnvFMBtfYNjAtYeqvHgNWmJjlwcUcZKi5AoISe4WgrKlprQPCsSajzZyLHNdT6euHZisQFZntYdch6HvmK8kspS6O1fpGaNBEkJ0htZQRZofg_zo92ctneFZd/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.ikjc500%2Fikj2l2_SUBMIT_command_operands.htm
Note [brightly highlighed]
All characters in the job stream are converted to uppercase
before being processed.

WTF!?  Does that mean that if I SUBMIT a job containing:
//SYSUT1  DD  *
This is Mixed Case text.
The effect is the same as:
//SYSUT1  DD  *
THIS IS MIXED CASE TEXT.

I don't remember it that way, but I confess I can't remember having
tried it.  Lately I've submitted only via FTP or copy to INTRDR.  But
is a clarification RCF in order?

I'd advocate RFEs for a
oSUBMIT FROMDDNAME(...) option
oRemoving the Fixed-80 restriction, relaxed for JES2 circa z/OS 1.5
 and for JESZ3 far earlier, but lingering in TSO/ISPF submit.

-- 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: JCL to include data

[Seymour J Metz]

Separate the JCL into a prefix member and a suffix member, then write a job to 
copy a concatenation of the pieces to the Internal Reader.

But if you don't need to do symbol substitution then you can just change your 
job to use DSN= instead of * or DATA.


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


From: IBM Mainframe Discussion List  on behalf of 
Mark Pace 
Sent: Monday, July 8, 2019 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL to include data

Working with a user that needs include a bunch of data in a JCL.  The data
is too large to copy into the JCL. During the copy he gets several E37s and
then ends with a B37.  It appears to me that he runs out of space in that
PDS.

The data that needs to be included is a flat file and not a PDS, which
seems to rule out the // INCULDE statement.

Any suggestions would be appreciated.

--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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: JCL to include data

[Paul Gilmartin]

On Mon, 8 Jul 2019 14:02:20 -0500, Elardus Engelbrecht wrote:
>...
>??? Please explain that. Do you mean, you want to add the members as an input 
>into that JCL? Why not just concatenate them using some DD statements?
> ...
>Why not use a [concatenated] DD refering to the source of that data in that 
>flat file / PDs / members of that PDS?
> 
Me, too.  But this thread inspired me to RTFM, where I see:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ikjc500/ikj2l2_SUBMIT_command_operands.htm
Note [brightly highlighed]
All characters in the job stream are converted to uppercase
before being processed.

WTF!?  Does that mean that if I SUBMIT a job containing:
//SYSUT1  DD  *
This is Mixed Case text.
The effect is the same as:
//SYSUT1  DD  *
THIS IS MIXED CASE TEXT.

I don't remember it that way, but I confess I can't remember having
tried it.  Lately I've submitted only via FTP or copy to INTRDR.  But
is a clarification RCF in order?

I'd advocate RFEs for a
oSUBMIT FROMDDNAME(...) option
oRemoving the Fixed-80 restriction, relaxed for JES2 circa z/OS 1.5
 and for JESZ3 far earlier, but lingering in TSO/ISPF submit.

-- gil

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

Re: JCL to include data

[Elardus Engelbrecht]

Mark Pace wrote:

>Working with a user that needs include a bunch of data in a JCL.  The data is 
>too large to copy into the JCL. During the copy he gets several E37s and then 
>ends with a B37. 

How is the JCL generated in the first place? Do you build up a large, extra 
large, extreme large dataset where you throw in the JCL and that "bunch of 
data" into it before giving it to JES2 internal reader?

Do you get the x37 abends before you or them are able to submit it in the first 
place?

Please post an example of that JCL and some sample of that "bunch of data".

Also, please post all the x37 abend messages.


> It appears to me that he runs out of space in that PDS.

??? Please explain that. Do you mean, you want to add the members as an input 
into that JCL? Why not just concatenate them using some DD statements?


>The data that needs to be included is a flat file and not a PDS, which seems 
>to rule out the // INCULDE statement.

Why not use a [concatenated] DD refering to the source of that data in that 
flat file / PDs / members of that PDS?

Groete / Greetings
Elardus Engelbrecht

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

Re: JCL to include data

[Paul Gilmartin]

On Mon, 8 Jul 2019 14:49:00 -0400, Mark Pace wrote:

>Working with a user that needs include a bunch of data in a JCL.  The data
>is too large to copy into the JCL. During the copy he gets several E37s and
>then ends with a B37.  It appears to me that he runs out of space in that
>PDS.
>
>The data that needs to be included is a flat file and not a PDS, which
>seems to rule out the // INCULDE statement.
>
>Any suggestions would be appreciated.
> 
"data" but not JCL statements?  I'm mystified.  Is this something that
can't be referenced in a //SYSUT1 DD DSN=... statement?

How large is it?  How many lines?  What facility is he using to "copy"?
Can he allocate a larger target PDS?  Can he copy directly to INTRDR?
Other relevant facts?

-- gil

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

Load Module lookup ?

[Lionel B Dyck]

I have some code that calls a load module.  In my unit test, both online and
batch, with a hard coded DD for ISPLLIB, the call to the program works using
both Address LINKMVS and Address ISPEXEC 'Select PGM(xxx)'. When I change to
use a LIBDEF both address Linkmvs and address ispexec select fail but do not
report an 806.

 

The only thing that actually works without the hardcoded DD is to call
'loadlib(lmod)' which I'm very reluctant to do but it's the only thing I can
for now.

 

I have a feeling this is something trivial that I'm just overlooking.

 

Advice please.

 

 

Lionel B. Dyck <
Website:   http://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

 


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

JCL to include data

[Mark Pace]

Working with a user that needs include a bunch of data in a JCL.  The data
is too large to copy into the JCL. During the copy he gets several E37s and
then ends with a B37.  It appears to me that he runs out of space in that
PDS.

The data that needs to be included is a flat file and not a PDS, which
seems to rule out the // INCULDE statement.

Any suggestions would be appreciated.

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: getting a list of FMIDS and the product description

[Cieri, Anthony]

How about the GIMXSID utility???

I believe that SMP/E provides sample JCL to execute GIMXSID to produce 
a consolidated inventory report to be used with ShopZ ordering. This is 
basically a list of FMIDs and features.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron van der Zande
Sent: Thursday, July 04, 2019 2:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: getting a list of FMIDS and the product description

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


LS;
Maybe you can use the following method.
16 Tables  ISPF Table Utility  
Edit table BCNFMDS
Export this table to a dataset.
Extract FMIDS from SMP LIST FEATURE and use the dataset to translate FMIDs to a 
product description.
Regards Ron vd Zande

Note: Could not found the magic button to add this text to original 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: WTO for message that will require explicit deletion?

[Seymour J Metz]

I would expect users to report it as a bug if they saw an outstanding WTOR with 
no surviving issuer.


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


From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Wednesday, July 3, 2019 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO for message that will require explicit deletion?

[Default] On 3 Jul 2019 09:12:55 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>I would expect cleanup of outstanding WTOs for any address space, be it a job 
>step, a started task, a tso session of a Unix shell.
>
I would expect WTORs to be cleaned up but I could see leaving a WTO
outstanding after the address space is long gone if the purpose is to
make sure some entity (person, console automation, etc.) reads the
message.

Clark Morris
>
>From: IBM Mainframe Discussion List  on behalf of 
>Charles Mills 
>Sent: Friday, June 28, 2019 4:49 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: WTO for message that will require explicit deletion?
>
>Thanks everyone for your input. Sorry for the delays in responding -- I was 
>OOO for a day plus.
>
>I am going to re-phrase this question and post it again. I am going to drop up 
>one level to the "real" problem to be solved.
>
>I *suspect* that my problem with DESC=3 not behaving exactly as I hoped may be 
>that it is coming from a batch program, and at end of step MVS effectively 
>DOM's the message. I am going to -- just as an experiment -- stick a one 
>minute delay into the program between the WTO and the return to MVS to see how 
>the message behaves in that case.
>
>Charles
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Tom Marchant
>Sent: Thursday, June 27, 2019 8:10 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: WTO for message that will require explicit deletion?
>
>On Wed, 26 Jun 2019 16:07:29 -0700, Charles Mills wrote:
>
>>My "console" experience is with SDSF LOG, not a real console, so my 
>>perception of where messages hang is a little skewed I guess.
>
>That is not a console at all, and doesn't behave like one. Messages
>that are not deletable (if the console is in RD mode), including WTOR
>messages, roll up to the top but do not roll off the top when other
>messages are issued. In SDSF outstanding reply messages are displayed
>at the bottom of the the LOG display, in addition to their original
>location. If I remember correctly non-deletable messages are flagged,
>IIRC with an "*". before the message.
>
>As Dave alluded to, a console lines are a very limited finite resource
>that has not significantly increased in capacity over the years. Even
>back in the early 80's many shops ran their consoles in roll mode
>rather than roll-deletable mode because too many programs issued
>either WTOR messages or non-deletable messages. Even way back then,
>when running a console in RD mode could cause the console to fill up
>with non-deletable messages and no new messages could be issued to
>that terminal, whether or not the new message is deletable.
>
>Indeed, when I started in this business in 1970 as a Cobol
>application programmer running  on MVT with three active regions,
>the rule that DISPLAY UPON CONSOLE was not to be used unless it was
>for an explicitly approved purpose, so as not to clutter the console
>
>I never worked as an operator, but in the late 70's to the mid 80's
>I worked as an Amdahl Field SE and would sometimes be at a console.
>Sometimes I would set the console in RD mode just to see what the
>message traffic looked like, and was occasionally surprised with
>how quickly the console would fill up with non-deletable messages.
>In those days it was unusual to have much more than 100 address
>spaces active.
>
>On the quite small LPAR that I am working at right now, there are 3
>25 started tasks active and 512 total address spaces. At the moment,
>there are 11 WTOR messages outstanding. That in itself is half of a
>24 x 80 3270 display (there are two lines for command input). Add s
>ome products that think that it is important to issue messages that
>stick on the console, and the console quickly becomes unusable in
>RD mode unless messages are explicitly deleted. In my opinion, the
>use of console messages, especially non-deletable messages, should
>be kept at a minimum.

--
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: SMPE ACCEPT options

[Seymour J Metz]

The only expensive backups I've encountered were the ones that I didn't take 
but should have. But it's not my dog.


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


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Wednesday, July 3, 2019 2:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE ACCEPT options

So, all you chronic backer uppers, how many times have you resorted to 
restoring the whole shebang? Just wondering...

.
.
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 
Allan Staller
Sent: Wednesday, July 3, 2019 11:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SMPE ACCEPT options

It is a common practice to back up everything before the accept.
In my case, the entire SMP/e ENV is on one volume, so I just use df/dss.

Any method that works for the backup is acceptable.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Wednesday, July 3, 2019 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE ACCEPT options

But first!
So, before running an accept w/o check, I should backup my CSI?
Should I do that "within" SMPE? Or can I just use idcams to backup my CSI 
cluster?
thanks
Bill


--
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: MXG error reading z/OS 2.3 data

[Scott Barry]

Recommend first-opportunity to upgrade SAS to a reasonably supported 
version/release and maintenance-level, given SAS 9.1.3 was reduced to very 
limited-support level back in 2013 -- also you are likely missing out on key 
usability improvements, some of which would naturally occur "under the covers" 
with hardware infrastructure changes.

Also, with z/OS V2.3 SMF data, strongly recommend reviewing the MXG.COM support 
site and the CHANGES page for MXG software maintenance-level with new-release 
and technology support.  As a general-rule, consider at least maintaining MXG 
software-currency with each annual-version.

Scott Barry
SBBWorks, Inc.


On Mon, 8 Jul 2019 11:33:53 +, Beesley, Paul  wrote:

>Using MXG 32.04 with SAS 9.1.3, reading a mix of z/OS 2.1 and 2.3 data, I get 
>this message and RC=4
>ERROR:  FOR FILE SMF, INVALID VBS SEGMENT DETECTED. PROCESSING IS CONTINUING 
>TO THE NEXT RECORD.
>Also tried using MXG 36.04 (which required hotfix 37166 for SAS).
>Processed only the 2.3 dataset to narrow it down.
>Is this anything to worry about?
>How can I tell which record it is complaining about?
>
>Thanks
>
>Paul
>
>Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
>names used by the Atos group. The following trading entities are registered in 
>England and Wales: Atos IT Services UK Limited (registered number 01245534), 
>Atos Consulting Limited (registered number 04312380), Atos Worldline UK 
>Limited (registered number 08514184) and Canopy The Open Cloud Company Limited 
>(registration number 08011902). The registered office for each is at Second 
>Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.  The VAT No. for 
>each is: GB232327983.
>
>This e-mail and the documents attached are confidential and intended solely 
>for the addressee, and may contain confidential or privileged information. If 
>you receive this e-mail in error, you are not authorised to copy, disclose, 
>use or retain it. Please notify the sender immediately and delete this email 
>from your systems. As emails may be intercepted, amended or lost, they are not 
>secure. Atos therefore can accept no liability for any errors or their 
>content. Although Atos endeavours to maintain a virus-free network, we do not 
>warrant that this transmission is virus-free and can accept no liability for 
>any damages resulting from any virus transmitted. The risks are deemed to be 
>accepted by everyone who communicates with Atos by email.
>
>--
>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: MXG error reading z/OS 2.3 data

[Elardus Engelbrecht]

Beesley, Paul wrote:

>Using MXG 32.04 with SAS 9.1.3, reading a mix of z/OS 2.1 and 2.3 data, I get 
>this message and RC=4
>ERROR:  FOR FILE SMF, INVALID VBS SEGMENT DETECTED. PROCESSING IS CONTINUING 
>TO THE NEXT RECORD.

I have used SAS many moons ago and I certainly remember this badd-a$$ message 
related to a bad SMF input...


>Is this anything to worry about?

Yes, loss of SMF data and angry readers of your SAS reports... ;-)


>How can I tell which record it is complaining about?

Hard to tell. Use IFASMFDP to copy your SMF records to other dataset. It will 
only read up to the very last readable record. The rest of the dataset are 
simply lost. (I think there is a freebie on CBT where you can re-join the parts 
of the SMF VBS dataset...)

Use that copy on your SAS/MXG job.

Groete / Greetings
Elardus Engelbrecht

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

Re: MXG error reading z/OS 2.3 data

[Carmen Vitullo]

Also, depending on the record type, I think Dr. Barry has some diagnostics when 
MXG hits an invalid SMF record, check your SASLOG for some diagnostics showing 
the invalid record(s). 
been a while since I've used SAS/MXG but I believe this is still the case 



Carmen Vitullo 

- Original Message -

From: "Ron Hawkins"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, July 8, 2019 9:59:40 AM 
Subject: Re: MXG error reading z/OS 2.3 data 

Paul, 

The problem is not SAS or MXG. 

It means you have an out-of-sequence or missing segment of a spanned record 
in the file. 


RON HAWKINS 
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) 
m+61 400029610| t: +1 4085625415 | f: +1 4087912585 

-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Beesley, Paul 
Sent: Monday, 8 July 2019 21:34 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [IBM-MAIN] MXG error reading z/OS 2.3 data 

Using MXG 32.04 with SAS 9.1.3, reading a mix of z/OS 2.1 and 2.3 data, I 
get this message and RC=4 
ERROR: FOR FILE SMF, INVALID VBS SEGMENT DETECTED. PROCESSING IS CONTINUING 
TO THE NEXT RECORD. 
Also tried using MXG 36.04 (which required hotfix 37166 for SAS). 
Processed only the 2.3 dataset to narrow it down. 
Is this anything to worry about? 
How can I tell which record it is complaining about? 

Thanks 

Paul 

Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are 
trading names used by the Atos group. The following trading entities are 
registered in England and Wales: Atos IT Services UK Limited (registered 
number 01245534), Atos Consulting Limited (registered number 04312380), Atos 
Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud 
Company Limited (registration number 08011902). The registered office for 
each is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA. 
The VAT No. for each is: GB232327983. 

This e-mail and the documents attached are confidential and intended solely 
for the addressee, and may contain confidential or privileged information. 
If you receive this e-mail in error, you are not authorised to copy, 
disclose, use or retain it. Please notify the sender immediately and delete 
this email from your systems. As emails may be intercepted, amended or lost, 
they are not secure. Atos therefore can accept no liability for any errors 
or their content. Although Atos endeavours to maintain a virus-free network, 
we do not warrant that this transmission is virus-free and can accept no 
liability for any damages resulting from any virus transmitted. The risks 
are deemed to be accepted by everyone who communicates with Atos by email. 

-- 
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: MXG error reading z/OS 2.3 data

[Ron Hawkins]

Paul,

The problem is not SAS or MXG.

It means you have an out-of-sequence or missing segment of a spanned record
in the file.


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Beesley, Paul
Sent: Monday, 8 July 2019 21:34
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] MXG error reading z/OS 2.3 data

Using MXG 32.04 with SAS 9.1.3, reading a mix of z/OS 2.1 and 2.3 data, I
get this message and RC=4
ERROR:  FOR FILE SMF, INVALID VBS SEGMENT DETECTED. PROCESSING IS CONTINUING
TO THE NEXT RECORD.
Also tried using MXG 36.04 (which required hotfix 37166 for SAS).
Processed only the 2.3 dataset to narrow it down.
Is this anything to worry about?
How can I tell which record it is complaining about?

Thanks

Paul

Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are
trading names used by the Atos group. The following trading entities are
registered in England and Wales: Atos IT Services UK Limited (registered
number 01245534), Atos Consulting Limited (registered number 04312380), Atos
Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud
Company Limited (registration number 08011902). The registered office for
each is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.
The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely
for the addressee, and may contain confidential or privileged information.
If you receive this e-mail in error, you are not authorised to copy,
disclose, use or retain it. Please notify the sender immediately and delete
this email from your systems. As emails may be intercepted, amended or lost,
they are not secure. Atos therefore can accept no liability for any errors
or their content. Although Atos endeavours to maintain a virus-free network,
we do not warrant that this transmission is virus-free and can accept no
liability for any damages resulting from any virus transmitted. The risks
are deemed to be accepted by everyone who communicates with Atos by email.

--
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: Dynamically changing paramters is TSOKEY00

[Elardus Engelbrecht]

Gadi Ben-Avi wrote:

>Is it possible to dynamically change parameters in TSOKEY00?
>HIBFREXT specifically.
>We are using z/OS v2.3.

Good question, it is a loong time ago I even looked at that parmlib member 
and that HIBFREXT... ;-)

I believe it is not possible to do that dynamically. I have to RTFM to see if 
there are commands you can give to the TSO address space, only modify command 
available is where you can refresh IKJTSOxx, which is not what you want.

I see in the IBM supplied PROC for IKTCAS00, the DD for PARMLIB is something 
like this:

//PARMLIB  DD  DSN=PARMLIB(TSOKEY..),DISP=SHR,FREE=CLOSE 

It looks it is open, read and close immediately.

After more RTFM it seemed to me, if something is wrong in the parmlib, the 
default values as programmed inside IKTCAS00 module are used instead.

Only "dynamic changes" available for TSOKEY00 are: stop and start.

Of course, I may be wrong ... 

Groete / Greetings
Elardus Engelbrecht

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

Re: Dynamically changing paramters is TSOKEY00

[Seymour J Metz]

You can change the IKJTSOxx parameters with the PARMLIB command but I don't 
know of any way to change the TSOKEYxx parameters dynamically, and at first 
glance it would be difficult for IBM to add dynamic changes.


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


From: IBM Mainframe Discussion List  on behalf of 
Gadi Ben-Avi 
Sent: Monday, July 8, 2019 6:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dynamically changing paramters is TSOKEY00

Hi,

Is it possible to dynamically change parameters in TSOKEY00?

HIBFREXT specifically.

We are using z/OS v2.3.

Thanks



Gadi

--
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: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency?

[Mohammad Khan]

That's only partly true. Of the three such languages that I'm familiar with, 
they all write the numbers so that higher order digits are to the left of lower 
order digits but not all of them read in left to right order. One of them reads 
the numbers right to left i.e. units tens hundreds order.

mkk

On Wed, 3 Jul 2019 17:14:12 +, Seymour J Metz  wrote:

>> I think the cultures that read from right to left number the pages that way 
>> also.
>
>The cultures that read from right to left still read Arabic numerals (not to 
>be confused with the numerals in the Arabic script) from left to right.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>

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

Re: SMPE ACCEPT options

[Tom Marchant]

On Wed, 3 Jul 2019 18:42:37 +, Jesse 1 Robinson wrote:

>So, all you chronic backer uppers, how many times have you 
>resorted to restoring the whole shebang? Just wondering...

Truth is, I never bothered to take an explicit backup. I felt that our 
regular full volume and incremental backups were adequate. And 
besides, I ALWAYS cloned my target and DLIB zones before 
applying maintenance, and could easily recreate an environment 
from a previous set. There have been a few times that I did that.

And I always use NOPURGE and NORERJECT in my options entry. 
With all those DLIB zones, I want things to stay in my Global 
zone until I know I'm finished with them.

Another question for those of you who like to back up everything. 
Do you include the Global zone in your "everything"?

-- 
Tom Marchant

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

Re: include library for @@CEETEST

[Joseph Reichman]

I have an Assembler started task communicating with a windows MFC program 

There is code that is similar to both thus I have decided to use c/c++ for this 
common code I normally use TEST to debug the Assembler from TSO but the C/C++ 
would be difficult thinking when I get to the ceetest is will invoke debug tool 
just not sure how debug tool handles DWARF format files or if I have to do any 
conversions 

Thanks 

> On Jul 8, 2019, at 8:34 AM, Lizette Koehler  wrote:
> 
> So I think this is should work.  I have not coded in C for a while.  Are you 
> using DEBUG process or do you want to eliminate DEBUG Process?
> 
> First you will need a compile/lked proc that will handle C code. There are .h 
>  libs you will need to have available for the process.
> 
> Then if your code looks like this
> 
> Following is an example of CEETEST called by C/C++.
> /*Module/File Name: EDCTEST   */
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main (void) {
> 
>   int x,y,z;
>   _VSTRING commands;
>   _FEEDBACK fc;
> 
>   strcpy(commands.string,
>"AT LINE 30 { LIST(x); LIST(y); GO; }");
>   commands.length = strlen(commands.string);
> 
>   CEETEST(&commands,&fc);
> 
>   if ( _FBCHECK ( fc , CEE000 ) != 0 ) {
>  printf("CEETEST failed with message number %d\n",
>  fc.tok_msgno);
>  exit(2999);
>   }
>   x = y = 12;
>  /* .
> .
> . */
>   /* debug tool displays the values of x and y */
>   /* at statement 30 */
>  /* .
> .
> . */
> }
> 
> Then the normal LE libraries and the .h libraries should pull it all together.
> 
> The LE manuals are decent on how to do this
> 
> Have you scanned SYS1.PROCLIB (or equivalent in your shop) for the C language 
> compile PROCs should begin with EDC as shipped by IBM?
> 
> That may help you with this process
> 
> Lizette
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of
>> Joseph Reichman
>> Sent: Monday, July 08, 2019 5:26 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: include library for @@CEETEST
>> 
>> I’m using XL C\C++. I’m thinking the #pragma map will give me the name
>> CEETEST name of the load module in CEE.SCEERUN wonder if I have to do a
>> pragma linkage  I think the call to ceetest is dynamic
>> 
>> 
>> 
>> 
>> 
>>> On Jul 8, 2019, at 8:23 AM, Lizette Koehler 
>> wrote:
>>> 
>>> What language and what error message are you getting?
>>> 
>>> What level of z/OS are you at?
>>> 
>>> Lizette
>>> 
>>> 
 -Original Message-
 From: IBM Mainframe Discussion List  On
 Behalf Of Joseph Reichman
 Sent: Sunday, July 07, 2019 5:35 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: include library for @@CEETEST
 
 Hi
 
 
 
 Would anyone know the include library for @@CEETEST
 
 
 
 I coded __ceeteest() and I guess the compiler mangled (for lack of a
 better
 term) I see CEETEST in CEE.SCEERUN alternativiliy
 
 
 
 is there some pragma option to get ride of @@ I looked in Chapter 18.
 z/OS XL C/C++ pragmas and didn't see any
 
 
 
 
 
 Thanks
 
 
 
> 
> --
> 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: include library for @@CEETEST

[Lizette Koehler]

So I think this is should work.  I have not coded in C for a while.  Are you 
using DEBUG process or do you want to eliminate DEBUG Process?

First you will need a compile/lked proc that will handle C code. There are .h  
libs you will need to have available for the process.

Then if your code looks like this

Following is an example of CEETEST called by C/C++.
/*Module/File Name: EDCTEST   */

#include 
#include 
#include 
#include 
#include 

int main (void) {

   int x,y,z;
   _VSTRING commands;
   _FEEDBACK fc;

   strcpy(commands.string,
"AT LINE 30 { LIST(x); LIST(y); GO; }");
   commands.length = strlen(commands.string);

   CEETEST(&commands,&fc);

   if ( _FBCHECK ( fc , CEE000 ) != 0 ) {
  printf("CEETEST failed with message number %d\n",
  fc.tok_msgno);
  exit(2999);
   }
   x = y = 12;
  /* .
 .
 . */
   /* debug tool displays the values of x and y */
   /* at statement 30 */
  /* .
 .
 . */
}

Then the normal LE libraries and the .h libraries should pull it all together.

The LE manuals are decent on how to do this

Have you scanned SYS1.PROCLIB (or equivalent in your shop) for the C language 
compile PROCs should begin with EDC as shipped by IBM?
 
That may help you with this process

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Joseph Reichman
> Sent: Monday, July 08, 2019 5:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: include library for @@CEETEST
> 
> I’m using XL C\C++. I’m thinking the #pragma map will give me the name
> CEETEST name of the load module in CEE.SCEERUN wonder if I have to do a
> pragma linkage  I think the call to ceetest is dynamic
> 
> 
> 
> 
> 
> > On Jul 8, 2019, at 8:23 AM, Lizette Koehler 
> wrote:
> >
> > What language and what error message are you getting?
> >
> > What level of z/OS are you at?
> >
> > Lizette
> >
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Joseph Reichman
> >> Sent: Sunday, July 07, 2019 5:35 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: include library for @@CEETEST
> >>
> >> Hi
> >>
> >>
> >>
> >> Would anyone know the include library for @@CEETEST
> >>
> >>
> >>
> >> I coded __ceeteest() and I guess the compiler mangled (for lack of a
> >> better
> >> term) I see CEETEST in CEE.SCEERUN alternativiliy
> >>
> >>
> >>
> >> is there some pragma option to get ride of @@ I looked in Chapter 18.
> >> z/OS XL C/C++ pragmas and didn't see any
> >>
> >>
> >>
> >>
> >>
> >> Thanks
> >>
> >>
> >>

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

Re: include library for @@CEETEST

[Joseph Reichman]

I’m using XL C\C++. I’m thinking the #pragma map will give me the name CEETEST 
name of the load module in CEE.SCEERUN wonder if I have to do a pragma linkage  
I think the call to ceetest is dynamic 





> On Jul 8, 2019, at 8:23 AM, Lizette Koehler  wrote:
> 
> What language and what error message are you getting?
> 
> What level of z/OS are you at?
> 
> Lizette
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of
>> Joseph Reichman
>> Sent: Sunday, July 07, 2019 5:35 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: include library for @@CEETEST
>> 
>> Hi
>> 
>> 
>> 
>> Would anyone know the include library for @@CEETEST
>> 
>> 
>> 
>> I coded __ceeteest() and I guess the compiler mangled (for lack of a better
>> term) I see CEETEST in CEE.SCEERUN alternativiliy
>> 
>> 
>> 
>> is there some pragma option to get ride of @@ I looked in Chapter 18. z/OS XL
>> C/C++ pragmas and didn't see any
>> 
>> 
>> 
>> 
>> 
>> Thanks
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> 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: include library for @@CEETEST

[Lizette Koehler]

What language and what error message are you getting?

What level of z/OS are you at?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Joseph Reichman
> Sent: Sunday, July 07, 2019 5:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: include library for @@CEETEST
> 
> Hi
> 
> 
> 
> Would anyone know the include library for @@CEETEST
> 
> 
> 
> I coded __ceeteest() and I guess the compiler mangled (for lack of a better
> term) I see CEETEST in CEE.SCEERUN alternativiliy
> 
> 
> 
> is there some pragma option to get ride of @@ I looked in Chapter 18. z/OS XL
> C/C++ pragmas and didn't see any
> 
> 
> 
> 
> 
> Thanks
> 
> 
> 
> 
> 
> 
> --
> 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: WTOR interactions (was: Best way to alert customer ...?)

[John McKown]

On Sat, Jul 6, 2019 at 2:28 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 5 Jul 2019 22:45:12 +, Jesse 1 Robinson wrote:
>
> >... If what's entered is not a real NetView command, you get this:
> >
> >   REPLY INVALID. REPLY WITH VALID NCCF SYSTEM OPERATOR COMMAND
> >
> >This can easily happen if the operator tries to reply to a different WTOR
> but gets the number wrong. Often this WTOR remains in this state for weeks
> or months. Until the next IPL. You never know what it didn't like because
> the bad reply has rolled off immediately. So my final piece of advice.
> Whatever mechanism you settle on, don't be like NetView.
> >
> On our test floor (perhaps too many) engineers had operator authority
> (I was among them.)  I remember watching another novice trying to deal
> with such as:
> 42 RESOURCE UNAVAILABLE.  REPLY 'CANCEL' OR WAIT
> R 42,WAIT
> REPLY 'WAIT' INVALID
> 43 RESOURCE UNAVAILABLE.  REPLY 'CANCEL' OR WAIT
> R 43,WAIT
> ...
>
> This process doesn't necessarily terminate.  It would have
> been far better if it were:
> 42 Resource unavailable.  Wait or reply 'CANCEL'

... Keeping 'WAIT' out of the scope of recommended replies.
> And using mixed case vs. upper case to differentiate instructions
> to operator from suggested replies.


I like that idea. But then again, we need to remember that this code is
likely ancient, perhaps from the days before 3270 consoles. When UPPER CASE
ruled the MVT+ world (it was a loud, angry time?). IIRC, there were some OS
consoles which would automatically upper case for display, but there were
others that would simply print a blank. Which is probably why these
messages are in upper case only.


> And one of my pet gripes is that  the reply number is incremented
> when the reply is rejected.  It would be far more intuitive if it allowed
> the operator to retry with *the*same* reply number.  I know; WAD.
> But the design is wrong in not considering that human factor.
>

As far as I know, the WTOR processing itself does not in any way validate
the data entered as the reply. It only validates the length of the data.
The code which issues the WTOR is what is validating the input. And, if
unacceptable (in this case), simply does another WTOR. Which is why the
reply number is incremented. The WTORs are completely separate so far as
the system is concerned. It might be interesting if WTOR had a "reissue"
option which would reuse the same reply number. But that would require more
bookkeeping. Or instead, have WTOR have two new options: "return reply id"
and "desired reply id" so that the first time, you could get the generated
reply id, and then request that value be used as the reply id for another
WTOR if it is available. A third optional option might be to have an
exhaustive list of acceptable replies and have WTOR itself validate the
data entered. But I think this is really off-the-wall and beyond the scope
of what WTOR should be doing. Personal opinion.


>
> -- gil
>
>
-- 
Money is the root of all evil.
Evil is the root of all money.
With that in mind, money is made by the government ...


Maranatha! <><
John McKown

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

MXG error reading z/OS 2.3 data

[Beesley, Paul]

Using MXG 32.04 with SAS 9.1.3, reading a mix of z/OS 2.1 and 2.3 data, I get 
this message and RC=4
ERROR:  FOR FILE SMF, INVALID VBS SEGMENT DETECTED. PROCESSING IS CONTINUING TO 
THE NEXT RECORD.
Also tried using MXG 36.04 (which required hotfix 37166 for SAS).
Processed only the 2.3 dataset to narrow it down.
Is this anything to worry about?
How can I tell which record it is complaining about?

Thanks

Paul

Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at Second 
Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.  The VAT No. for each 
is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

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

Dynamically changing paramters is TSOKEY00

[Gadi Ben-Avi]

Hi,

Is it possible to dynamically change parameters in TSOKEY00?

HIBFREXT specifically.

We are using z/OS v2.3.

Thanks



Gadi

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

Re: WTOR interactions (was: Best way to alert customer ...?)

[Binyamin Dissen]

Bright side is that it is pretty easy to change with an MPF exit.

On Sat, 6 Jul 2019 14:28:28 -0500 Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

:>On Fri, 5 Jul 2019 22:45:12 +, Jesse 1 Robinson wrote:
:>
:>>... If what's entered is not a real NetView command, you get this:
:>>
:>>   REPLY INVALID. REPLY WITH VALID NCCF SYSTEM OPERATOR COMMAND
:>>
:>>This can easily happen if the operator tries to reply to a different WTOR 
but gets the number wrong. Often this WTOR remains in this state for weeks or 
months. Until the next IPL. You never know what it didn't like because the bad 
reply has rolled off immediately. So my final piece of advice. Whatever 
mechanism you settle on, don't be like NetView. 
:>>
:>On our test floor (perhaps too many) engineers had operator authority
:>(I was among them.)  I remember watching another novice trying to deal
:>with such as:
:>42 RESOURCE UNAVAILABLE.  REPLY 'CANCEL' OR WAIT
:>R 42,WAIT
:>REPLY 'WAIT' INVALID
:>43 RESOURCE UNAVAILABLE.  REPLY 'CANCEL' OR WAIT
:>R 43,WAIT
:>...
:>
:>This process doesn't necessarily terminate.  It would have
:>been far better if it were:
:>42 Resource unavailable.  Wait or reply 'CANCEL'
:>... Keeping 'WAIT' out of the scope of recommended replies.
:>And using mixed case vs. upper case to differentiate instructions
:>to operator from suggested replies.
:>
:>And one of my pet gripes is that  the reply number is incremented
:>when the reply is rejected.  It would be far more intuitive if it allowed
:>the operator to retry with *the*same* reply number.  I know; WAD.
:>But the design is wrong in not considering that human factor.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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