Re: Silly C problem adding hex 6C

[Barkow, Eileen]

How do you specify the item size when adding?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Thursday, February 08, 2018 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

Isn't pointer arithmetic in C scaled by the item size?


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


From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen 
Sent: Thursday, February 8, 2018 11:06 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Silly C problem adding  hex 6C

I am still trying to crawl my way around C/C++ and am just trying to do one 
simple thing:
add value 0X6C to a pointer address (which was originally supplied by this list 
as a means to get the jobname).
 something gets added to the pointer but it is not 0x6c.
i tried all different combinations of char *; int *; void *; adding decimal 
108; but still get the same thing.

My little program correctly picks up the address of a valid ASCB (00FCAA00) 
from the PSA.
Now I just want to point to the address at 00FCAA6C which is a pointer to the 
ASXB which contains the jobname at offset 0XC0.

But somehow I cannot add 6C to the ASCB pointer FCAA00 and get the ASXB pointer 
at FCAA6C.
Instead I get FCABB0 (or some other address depending on which ASCB is 
obtained).
Can some C guru please tell me what I am doing wrong?

i will post the program and results - this is running on UNIX/OMVS.


 MVSZ MVSZ - Storage Contents : ACSCEXB -- (00FCAA00,,SQA) ---
 Command ===>  Scroll ===> PAG

 Address  Offset  0-1-2-3-  4-5-6-7-  8-9-A-B-  C-D-E-F-0---4---8---C---
 00FCAA00 +0  C1E2C3C2  00FBC100  00FCAB80    | ASCB..A...¿Ø |
 00FCAA10+10          |  |
 00FCAA20+20  02E4  0078  000100FF    | ...U.Ì.. |
 00FCAA30+30  7FF19E00    19A77000    | "1Æ..xø. |
 00FCAA40+40    00308F46  D3DC5674  8B346008  | ..±ãLüîÈ».-. |
 00FCAA50+50          |  |
 00FCAA60+60  00AFF158  8F80    00AFD000  | .®1ì..±Ø.®}. |
 00FCAA70+70  1D171020      00AFD520  | .®N. |
 00FCAA80+80      80AFFF98  4000  | Ø®.q ... |

 result running jn2
$ jn2
ASCB = FCAA00
ASXB =  FCABB0
$

jn2.c program

#define _XOPEN_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
int main(int argc, char *argv[])
 {
int *PSA;
int  *ASCB;
int  *ASXB;
char jobname[9];
PSA=(int *)0x224; /* address of PSAAOLD */
ASCB=(int *)*PSA;
printf("ASCB = %X\n",ASCB);
ASXB=ASCB+0x6c;
printf("ASXB =  %X\n",ASXB);
}

to compile:
c++ -+ -c -o jn2.o -I/u/eileen/j16/cons \
 -I/usr/lpp/java/J8.0_64/include \
 -W"c,lp64,dll,xplink,langlvl(longlong,nullptr)" jn2.c

to link:
c++ \
-W l,AMODE=64,lp64,LET=4,xplink,dynam=dll,case=mixed \
-I=CELQS003.x \
-o jn2\
  linkmods/CELQSTRT.o \
 linkmods/CEESTART.o \
 linkmods/CELQSG03.o \
 linkmods/CELQINPL.o \
 linkmods/CELQETBL.o \
 linkmods/CELQLLST.o \
 linkmods/CELQBST.o \
 linkmods/CELQTRM.o \
 jn2.o



  

This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.


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

[Seymour J Metz]

Why do you need windowing? What you need is to mage the pages, and the same 
issues exist whether the mapping is windowed or direct into virtual memory.


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


From: IBM Mainframe Discussion List  on behalf of 
Tony Harminc 
Sent: Wednesday, February 7, 2018 6:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: codepages

On 6 February 2018 at 14:17, Peter Hunkeler  wrote:
>> Isn't this what DIV is for?
>
> DIV works with VSAM linear data sets. How would it help here?

The discussion has been (mostly) about loading an entire dataset into
virtual storage (as ISPF Edit does) vs windowing techniques that avoid
requiring a huge amount of virtual.

I wasn't suggesting that DIV could apply directly to (say) a PS or PO
dataset, but if you want to implement windowing you need some scheme
to map file data to a smaller amount of virtual storage. DIV would
seem to be a base to build on.

Tony H.

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

Silly C problem adding hex 6C

[Barkow, Eileen]

I am still trying to crawl my way around C/C++ and am just trying to do one 
simple thing:
add value 0X6C to a pointer address (which was originally supplied by this list 
as a means to get the jobname).
 something gets added to the pointer but it is not 0x6c.
i tried all different combinations of char *; int *; void *; adding decimal 
108; but still get the same thing.

My little program correctly picks up the address of a valid ASCB (00FCAA00) 
from the PSA.
Now I just want to point to the address at 00FCAA6C which is a pointer to the 
ASXB which contains the jobname at offset 0XC0.

But somehow I cannot add 6C to the ASCB pointer FCAA00 and get the ASXB pointer 
at FCAA6C.
Instead I get FCABB0 (or some other address depending on which ASCB is 
obtained).
Can some C guru please tell me what I am doing wrong?

i will post the program and results - this is running on UNIX/OMVS.


 MVSZ MVSZ - Storage Contents : ACSCEXB -- (00FCAA00,,SQA) ---
 Command ===>  Scroll ===> PAG

 Address  Offset  0-1-2-3-  4-5-6-7-  8-9-A-B-  C-D-E-F-0---4---8---C---
 00FCAA00 +0  C1E2C3C2  00FBC100  00FCAB80    | ASCB..A...¿Ø |
 00FCAA10+10          |  |
 00FCAA20+20  02E4  0078  000100FF    | ...U.Ì.. |
 00FCAA30+30  7FF19E00    19A77000    | "1Æ..xø. |
 00FCAA40+40    00308F46  D3DC5674  8B346008  | ..±ãLüîÈ».-. |
 00FCAA50+50          |  |
 00FCAA60+60  00AFF158  8F80    00AFD000  | .®1ì..±Ø.®}. |
 00FCAA70+70  1D171020      00AFD520  | .®N. |
 00FCAA80+80      80AFFF98  4000  | Ø®.q ... |

 result running jn2
$ jn2
ASCB = FCAA00
ASXB =  FCABB0
$

jn2.c program

#define _XOPEN_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
int main(int argc, char *argv[])
 {
int *PSA;
int  *ASCB;
int  *ASXB;
char jobname[9];
PSA=(int *)0x224; /* address of PSAAOLD */
ASCB=(int *)*PSA;
printf("ASCB = %X\n",ASCB);
ASXB=ASCB+0x6c;
printf("ASXB =  %X\n",ASXB);
}

to compile:
c++ -+ -c -o jn2.o -I/u/eileen/j16/cons \
 -I/usr/lpp/java/J8.0_64/include \
 -W"c,lp64,dll,xplink,langlvl(longlong,nullptr)" jn2.c

to link:
c++ \
-W l,AMODE=64,lp64,LET=4,xplink,dynam=dll,case=mixed \
-I=CELQS003.x \
-o jn2\
  linkmods/CELQSTRT.o \
 linkmods/CEESTART.o \
 linkmods/CELQSG03.o \
 linkmods/CELQINPL.o \
 linkmods/CELQETBL.o \
 linkmods/CELQLLST.o \
 linkmods/CELQBST.o \
 linkmods/CELQTRM.o \
 jn2.o



  

This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.


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

Re: Silly C problem adding hex 6C

[Charles Mills]

Yes, pointer arithmetic is scaled by the item size. Works kind of like a
subscript. If foo is an int* then foo+1 points to the next integer. (IOW
foo+4 if you think in assembler terms.)

The basic strategy is to cast it to a char* and then back.

If you would like, here are two template functions that will do the trick
you want to accomplish.

// Pointer absolute arithmetic
// This one matches if no explicit typename
template static inline T *PointerAdd(const T *ptr, const int
increment)
{
return (T *)( reinterpret_cast(ptr)+increment );
}

// This one matches if explicit typename
template static inline T *PointerAdd(const void *ptr, const
int increment)
{
return (T *)( reinterpret_cast(ptr)+increment );
}

How to use? Here is an example of adding an absolute length to a struct
pointer:

apfePtr = PointerAdd(apfePtr, apfePtr->apfelen);

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, February 8, 2018 8:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

Isn't pointer arithmetic in C scaled by the item size?

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

Re: Silly C problem adding hex 6C

[Seymour J Metz]

Isn't pointer arithmetic in C scaled by the item size?


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


From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen 
Sent: Thursday, February 8, 2018 11:06 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Silly C problem adding  hex 6C

I am still trying to crawl my way around C/C++ and am just trying to do one 
simple thing:
add value 0X6C to a pointer address (which was originally supplied by this list 
as a means to get the jobname).
 something gets added to the pointer but it is not 0x6c.
i tried all different combinations of char *; int *; void *; adding decimal 
108; but still get the same thing.

My little program correctly picks up the address of a valid ASCB (00FCAA00) 
from the PSA.
Now I just want to point to the address at 00FCAA6C which is a pointer to the 
ASXB which contains the jobname at offset 0XC0.

But somehow I cannot add 6C to the ASCB pointer FCAA00 and get the ASXB pointer 
at FCAA6C.
Instead I get FCABB0 (or some other address depending on which ASCB is 
obtained).
Can some C guru please tell me what I am doing wrong?

i will post the program and results - this is running on UNIX/OMVS.


 MVSZ MVSZ - Storage Contents : ACSCEXB -- (00FCAA00,,SQA) ---
 Command ===>  Scroll ===> PAG

 Address  Offset  0-1-2-3-  4-5-6-7-  8-9-A-B-  C-D-E-F-0---4---8---C---
 00FCAA00 +0  C1E2C3C2  00FBC100  00FCAB80    | ASCB..A...¿Ø |
 00FCAA10+10          |  |
 00FCAA20+20  02E4  0078  000100FF    | ...U.Ì.. |
 00FCAA30+30  7FF19E00    19A77000    | "1Æ..xø. |
 00FCAA40+40    00308F46  D3DC5674  8B346008  | ..±ãLüîÈ».-. |
 00FCAA50+50          |  |
 00FCAA60+60  00AFF158  8F80    00AFD000  | .®1ì..±Ø.®}. |
 00FCAA70+70  1D171020      00AFD520  | .®N. |
 00FCAA80+80      80AFFF98  4000  | Ø®.q ... |

 result running jn2
$ jn2
ASCB = FCAA00
ASXB =  FCABB0
$

jn2.c program

#define _XOPEN_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
int main(int argc, char *argv[])
 {
int *PSA;
int  *ASCB;
int  *ASXB;
char jobname[9];
PSA=(int *)0x224; /* address of PSAAOLD */
ASCB=(int *)*PSA;
printf("ASCB = %X\n",ASCB);
ASXB=ASCB+0x6c;
printf("ASXB =  %X\n",ASXB);
}

to compile:
c++ -+ -c -o jn2.o -I/u/eileen/j16/cons \
 -I/usr/lpp/java/J8.0_64/include \
 -W"c,lp64,dll,xplink,langlvl(longlong,nullptr)" jn2.c

to link:
c++ \
-W l,AMODE=64,lp64,LET=4,xplink,dynam=dll,case=mixed \
-I=CELQS003.x \
-o jn2\
  linkmods/CELQSTRT.o \
 linkmods/CEESTART.o \
 linkmods/CELQSG03.o \
 linkmods/CELQINPL.o \
 linkmods/CELQETBL.o \
 linkmods/CELQLLST.o \
 linkmods/CELQBST.o \
 linkmods/CELQTRM.o \
 jn2.o



  

This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.


--
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: Insomnia cure

[Mark Jacobs - Listserv]

I've always used the RACROUTE Macro Reference manual as a sleep aid.

Nightwatch RenBand
February 8, 2018 at 11:49 AM
> I greatly appreciate all the input I am receiving as I get through the
"Insomnia Cure"I mean the > IBM Red Book on Setting up a Sysplex.

Thank, Fred G..
For several decades I have kept various IBM manuals by my bed as an
"insomnia cure". I suspect I will continue after I retire because it
always works. Surprised IBM has not figured out how to make money off
this.

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



Please be alert for any emails that may ask you for login information or 
directs you to login via a link. If you believe this message is a phish or 
aren't sure whether this message is trustworthy, please send the original 
message as an attachment to 
'phish...@meredith.com'.


--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


This electronic message, including any attachments, may contain proprietary, 
confidential or privileged information for the sole use of the intended 
recipient(s). You are hereby notified that any unauthorized disclosure, 
copying, distribution, or use of this message is prohibited. If you have 
received this message in error, please immediately notify the sender by reply 
e-mail and delete it.

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

Re: Silly C problem adding hex 6C

[Barkow, Eileen]

I tried the simplest solution of casting ASXB to a  CHAR * since I am not 
familiar with templates and  basically got the same value as before.
I will try some of the other solutions .

Thanks everyone
 $ jn2
ASCB = FB7A00
ASXBC =  FB7BB0


int *PSA;
 int  *ASCB;
 int  *ASXB=nullptr;
 char *ASXBC;
 char jobnameÝ9¨;
 PSA=(int *)0x224; /* address of PSAAOLD */
 ASCB=(int *)*PSA;
 printf("ASCB = %X\n",ASCB);
 ASXBC= (char *)(ASCB + 0x6c);
 printf("ASXBC =  %X\n",ASXBC);

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, February 08, 2018 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

On Thu, 8 Feb 2018 10:22:40 -0600, Allan Kielstra wrote:

>The size of a char in 1 byte.  Try
>
>(char *) ASXB = (char *) ASCB + 0x6c;  /* lazy version */
>
ANSI says a cast may not be used as an L-value.  IBM's C compiler
enforces this.  I once did something like (IIRC?):
*(char * *) ASXB += 0x6c;

My head hurts.

-- gil

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




This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.

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

SMF advice on additional logstreams

[Richards, Robert B.]

It was recently noticed that SMF TYPES 92 and 99 are creating a very high 
percentage of our overall SMF records. Seems to coincide with the 
implementation of z/OS 2.2, but that is speculative at the moment.

Has anyone considered (or implemented) making one or both into their own 
logstream(s)?  What about TYPE 120s from WebSphere?

At present, I have DEFAULT, RMF, RACF and DB2 with the usual types.

Thanks in advance, for your viewpoint(s).

Bob

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

Re: SMF advice on additional logstreams

[Rob Scott]

I have always thought of SMF92 and SMF99 as data of interest primarily for 
monitoring products - do you have them enabled because of ISV requirements?

If there is ISV software that needs to read this SMF data in real time (eg via 
IEFU8x) but there is no need for historical storage for these types, perhaps 
the vendor (or you) could create a simple IEFU8x to suppress these records from 
being hardened to MANx datasets or logstreams.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Thursday, February 8, 2018 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF advice on additional logstreams

It was recently noticed that SMF TYPES 92 and 99 are creating a very high 
percentage of our overall SMF records. Seems to coincide with the 
implementation of z/OS 2.2, but that is speculative at the moment.

Has anyone considered (or implemented) making one or both into their own 
logstream(s)?  What about TYPE 120s from WebSphere?

At present, I have DEFAULT, RMF, RACF and DB2 with the usual types.

Thanks in advance, for your viewpoint(s).

Bob

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Silly C problem adding hex 6C

[Richard Rogers]

(char *)(ASCB + 0x6C) is going to add 0x6c * 4 since ASCB is a pointer to 
integer, then that will be recast to a char *.
(char *)ASCB + 06C will add 0x6c.

Define everything as unsigned char *, since that's what you're really pointing 
to.  Then recast to int or whatever when and as actually used.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barkow, Eileen
Sent: Thursday, February 08, 2018 11:14
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

I tried the simplest solution of casting ASXB to a  CHAR * since I am not 
familiar with templates and  basically got the same value as before.
I will try some of the other solutions .

Thanks everyone  $ jn2 ASCB = FB7A00 ASXBC =  FB7BB0


int *PSA;
 int  *ASCB;
 int  *ASXB=nullptr;
 char *ASXBC;
 char jobnameÝ9¨;
 PSA=(int *)0x224; /* address of PSAAOLD */  ASCB=(int *)*PSA;  printf("ASCB = 
%X\n",ASCB);  ASXBC= (char *)(ASCB + 0x6c);  printf("ASXBC =  %X\n",ASXBC);

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, February 08, 2018 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

On Thu, 8 Feb 2018 10:22:40 -0600, Allan Kielstra wrote:

>The size of a char in 1 byte.  Try
>
>(char *) ASXB = (char *) ASCB + 0x6c;  /* lazy version */
>
ANSI says a cast may not be used as an L-value.  IBM's C compiler enforces 
this.  I once did something like (IIRC?):
*(char * *) ASXB += 0x6c;

My head hurts.

-- gil

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




This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.

--
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: SMF advice on additional logstreams

[Richards, Robert B.]

Rob,

> do you have them enabled because of ISV requirements?

Not intentionally, but you raise a point I need to consider. I am getting ready 
to install TMONMVS 4.8 which will now have their former standalone USS product 
integrated within it. I should probably wait until I review the installation 
requirements.

Bob
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Scott
Sent: Thursday, February 08, 2018 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF advice on additional logstreams

I have always thought of SMF92 and SMF99 as data of interest primarily for 
monitoring products - do you have them enabled because of ISV requirements?

If there is ISV software that needs to read this SMF data in real time (eg via 
IEFU8x) but there is no need for historical storage for these types, perhaps 
the vendor (or you) could create a simple IEFU8x to suppress these records from 
being hardened to MANx datasets or logstreams.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Thursday, February 8, 2018 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF advice on additional logstreams

It was recently noticed that SMF TYPES 92 and 99 are creating a very high 
percentage of our overall SMF records. Seems to coincide with the 
implementation of z/OS 2.2, but that is speculative at the moment.

Has anyone considered (or implemented) making one or both into their own 
logstream(s)?  What about TYPE 120s from WebSphere?

At present, I have DEFAULT, RMF, RACF and DB2 with the usual types.

Thanks in advance, for your viewpoint(s).

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
 Rocket Software, Inc. and subsidiaries ■ 77 
Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

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

Re: Silly C problem adding hex 6C

[Allan Kielstra]

The size of a char in 1 byte.  Try

(char *) ASXB = (char *) ASCB + 0x6c;  /* lazy version */

But that's not really very nice C code.  Rather than using int * variables, it 
would be preferable to provide a C struct describing the layout of storage and 
using a pointer (or a pointer to a pointer) of that type.

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

Insomnia cure

[Nightwatch RenBand]

 > I greatly appreciate all the input I am receiving as I get through the
"Insomnia Cure"I mean the > IBM Red Book on Setting up a Sysplex.

Thank, Fred G..
For several decades I have kept various IBM manuals by my bed as an
"insomnia cure".  I suspect I will continue after I retire because it
always works.  Surprised IBM has not figured out how to make money off
this.

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

Re: Silly C problem adding hex 6C

[Paul Gilmartin]

On Thu, 8 Feb 2018 10:22:40 -0600, Allan Kielstra wrote:

>The size of a char in 1 byte.  Try
>
>(char *) ASXB = (char *) ASCB + 0x6c;  /* lazy version */
> 
ANSI says a cast may not be used as an L-value.  IBM's C compiler
enforces this.  I once did something like (IIRC?):
*(char * *) ASXB += 0x6c;

My head hurts.

-- gil

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

Re: Silly C problem adding hex 6C

[Paul Gilmartin]

On Thu, 8 Feb 2018 16:45:18 +, Barkow, Eileen wrote:

>Thank you Charles and Seymore. I thought that the problem had something to do 
>with adding to pointers but
>I could not find any doc about it in the manuals.
>
In fact, subscripting is defined in terms of addition and dereferencing.  So:
Array[ index ]  means  *( Array + index )

Since addition is commutative, this is entirely equivalent to *( index + Array )
so, index[ Array ].

Or, an outrageous example:
"wombat"[ 3 ]  means the same as  3[ "wombat" ]  --  both mean 'b'.

Don't you ever dare code that!

>I am still not sure that I understand how to fix it but I will try based on 
>your info.

-- gil

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

Re: Silly C problem adding hex 6C

[Charles Mills]

Let's say foo is a struct with some variable length, typical of various MVS
data areas.

struct foo *pFoo;

If you say pFoo++ it increments pFoo by the declared static length of a foo,
not by 1. Increments by the declared length of struct foo.

If bar is an integer that has the actual length of this particular foo and
you want to increment pFoo by that amount, then you could code

pFoo = (foo *)((char *)foo + bar);

You are casting foo to a char* so ++ would add one to it. Then you add bar
(absolute value in bar) and then cast back to a foo* so you can assign it to
pFoo.

My two templates "automate" that (C++ only).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Barkow, Eileen
Sent: Thursday, February 8, 2018 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

Thank you Charles and Seymore. I thought that the problem had something to
do with adding to pointers but I could not find any doc about it in the
manuals.
I am still not sure that I understand how to fix it but I will try based on
your info.

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

Re: Silly C problem adding hex 6C

[John McKown]

On Thu, Feb 8, 2018 at 11:39 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 8 Feb 2018 10:22:40 -0600, Allan Kielstra wrote:
>
> >The size of a char in 1 byte.  Try
> >
> >(char *) ASXB = (char *) ASCB + 0x6c;  /* lazy version */
> >
> ANSI says a cast may not be used as an L-value.  IBM's C compiler
> enforces this.  I once did something like (IIRC?):
> *(char * *) ASXB += 0x6c;
>

​I did it this way:

char *psaaold;
char *ascbjbni;
unsigned char *ascbjbns;
unsigned char *ascbjbn;
unsigned char *a;
unsigned char jobname[9];
psaaold = *(unsigned char **)0x224; /* address of PSAAOLD */
ascbjbni = *(unsigned char **)(psaaold + 0xac);
ascbjbns = *(unsigned char **)(psaaold + 0xb0);​



>
> My head hurts.
>
> -- gil
>


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Silly C problem adding hex 6C

[Allan Kielstra]

Now you ran into another problem


(((char *)pointer) + offset)
is how you want to bind that expression.

(And I still think using structs is better)

(and you may have to add (int*) in front of the line above)

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

Re: SMF advice on additional logstreams

[Allan Staller]

Not sure about SMF92, but SMF99 are "WLM decision records".

Yes they are large volume, but somewhat indispensable.

Generally when there is a WLM problem it is extremely difficult or impossible 
to reproduce.
If the SMF99's are not available "during the problem" it is virtually 
impossible to debug.

IMO, SMF99's should be recorded.  I know Cheryl Watson and others may disagree.

My USD $0.02 worth,

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Scott
Sent: Thursday, February 8, 2018 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF advice on additional logstreams

I have always thought of SMF92 and SMF99 as data of interest primarily for 
monitoring products - do you have them enabled because of ISV requirements?

If there is ISV software that needs to read this SMF data in real time (eg via 
IEFU8x) but there is no need for historical storage for these types, perhaps 
the vendor (or you) could create a simple IEFU8x to suppress these records from 
being hardened to MANx datasets or logstreams.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Thursday, February 8, 2018 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF advice on additional logstreams

It was recently noticed that SMF TYPES 92 and 99 are creating a very high 
percentage of our overall SMF records. Seems to coincide with the 
implementation of z/OS 2.2, but that is speculative at the moment.

Has anyone considered (or implemented) making one or both into their own 
logstream(s)?  What about TYPE 120s from WebSphere?

At present, I have DEFAULT, RMF, RACF and DB2 with the usual types.

Thanks in advance, for your viewpoint(s).

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
 Rocket Software, Inc. and subsidiaries ■ 77 
Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 
Contact Customer Support: 
https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=lUU8KyIIZ5UpJX6ypDL%2FvS6%2Fd21%2BHuYJaq8FhqZD%2Bf8%3D=0
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=XXMltfkhIrQuNXdspClQAO4JClJMSbbTSDYMCitv7ZA%3D=0
Privacy Policy - 
https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=yOfhey0%2BRjTNYEaeidsV%2BoT6WS3XCJXjDy6UHsZt0z0%3D=0


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before 

Re: Silly C problem adding hex 6C

[Seymour J Metz]

You use an appropriate type when you declare the pointer. ISAGN for unspec.


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


From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen 
Sent: Thursday, February 8, 2018 11:15:32 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Silly C problem adding  hex 6C

How do you specify the item size when adding?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Thursday, February 08, 2018 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

Isn't pointer arithmetic in C scaled by the item size?


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


From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen 
Sent: Thursday, February 8, 2018 11:06 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Silly C problem adding  hex 6C

I am still trying to crawl my way around C/C++ and am just trying to do one 
simple thing:
add value 0X6C to a pointer address (which was originally supplied by this list 
as a means to get the jobname).
 something gets added to the pointer but it is not 0x6c.
i tried all different combinations of char *; int *; void *; adding decimal 
108; but still get the same thing.

My little program correctly picks up the address of a valid ASCB (00FCAA00) 
from the PSA.
Now I just want to point to the address at 00FCAA6C which is a pointer to the 
ASXB which contains the jobname at offset 0XC0.

But somehow I cannot add 6C to the ASCB pointer FCAA00 and get the ASXB pointer 
at FCAA6C.
Instead I get FCABB0 (or some other address depending on which ASCB is 
obtained).
Can some C guru please tell me what I am doing wrong?

i will post the program and results - this is running on UNIX/OMVS.


 MVSZ MVSZ - Storage Contents : ACSCEXB -- (00FCAA00,,SQA) ---
 Command ===>  Scroll ===> PAG

 Address  Offset  0-1-2-3-  4-5-6-7-  8-9-A-B-  C-D-E-F-0---4---8---C---
 00FCAA00 +0  C1E2C3C2  00FBC100  00FCAB80    | ASCB..A...¿Ø |
 00FCAA10+10          |  |
 00FCAA20+20  02E4  0078  000100FF    | ...U.Ì.. |
 00FCAA30+30  7FF19E00    19A77000    | "1Æ..xø. |
 00FCAA40+40    00308F46  D3DC5674  8B346008  | ..±ãLüîÈ».-. |
 00FCAA50+50          |  |
 00FCAA60+60  00AFF158  8F80    00AFD000  | .®1ì..±Ø.®}. |
 00FCAA70+70  1D171020      00AFD520  | .®N. |
 00FCAA80+80      80AFFF98  4000  | Ø®.q ... |

 result running jn2
$ jn2
ASCB = FCAA00
ASXB =  FCABB0
$

jn2.c program

#define _XOPEN_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
int main(int argc, char *argv[])
 {
int *PSA;
int  *ASCB;
int  *ASXB;
char jobname[9];
PSA=(int *)0x224; /* address of PSAAOLD */
ASCB=(int *)*PSA;
printf("ASCB = %X\n",ASCB);
ASXB=ASCB+0x6c;
printf("ASXB =  %X\n",ASXB);
}

to compile:
c++ -+ -c -o jn2.o -I/u/eileen/j16/cons \
 -I/usr/lpp/java/J8.0_64/include \
 -W"c,lp64,dll,xplink,langlvl(longlong,nullptr)" jn2.c

to link:
c++ \
-W l,AMODE=64,lp64,LET=4,xplink,dynam=dll,case=mixed \
-I=CELQS003.x \
-o jn2\
  linkmods/CELQSTRT.o \
 linkmods/CEESTART.o \
 linkmods/CELQSG03.o \
 linkmods/CELQINPL.o \
 linkmods/CELQETBL.o \
 linkmods/CELQLLST.o \
 linkmods/CELQBST.o \
 linkmods/CELQTRM.o \
 jn2.o



  

This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.


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

Re: Silly C problem adding hex 6C

[Charles Mills]

Will not win any prizes from your Computer Science professor but may well be 
the best way to skin the cat.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richard Rogers
Sent: Thursday, February 8, 2018 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

(char *)(ASCB + 0x6C) is going to add 0x6c * 4 since ASCB is a pointer to 
integer, then that will be recast to a char *.
(char *)ASCB + 06C will add 0x6c.

Define everything as unsigned char *, since that's what you're really pointing 
to.  Then recast to int or whatever when and as actually used.

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

Re: Delete dataset catch-22

[Burrell, Todd]

What do you get if you try this in IDCAMS:

  DEFINE NONVSAM(NAME(MARPACE.GODADDY.CERT) -
 DEVT(3390) VOLUME(STDL09)) 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Thursday, February 08, 2018 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Delete dataset catch-22

I'm trying to delete a dataset that is not cataloged any longer.  I'm not sure 
why it is not in a catalog, but it is not.  I've tried to re-catalog the 
dataset, but it doesn't catalog.

So I have tried to every combination of IDCAMS DELETE I can think of.
NONVSAM
NVR
etc..

All return
** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - Dataset not 
found.

So I tried IEHPROGM
  SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE

IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E), 
STEP010,STDL09,MARPACE.GODADDY.CERT

0406001E -  Verification of SMS flags failed; caller indicates the data set is 
not cataloged, but the *FMT1 DSCB indicates the data set is cataloged*

So I have no idea how to remove this dataset, IDCAMS won't do it because it's 
not in a catalog, and IEHPROGM won't do it because it thinks it is in a catalog.

Anyone have a suggestion?

Thank you.



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



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.


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

Re: Silly C problem adding hex 6C

[Bernd Oppolzer]

To be more pedantic, use additional parantheses:

ASXB = (int *) (((char *) ASCB) + 0x6c);

Kind regards

Bernd


Am 08.02.2018 um 20:47 schrieb Bernd Oppolzer:

int *ASCB;
int  *ASXB;
ASXB = ASCB + 0x6c;

because ASCB is a pointer to int, and int has sizeof = 4,
you are in fact adding 4 * 0x6c to ASCB, that's your problem.

use the following notation, and it will work:

ASXB = (int *) ((char *) ASCB + 0x6c);

first you cast the ASCB to a char *, then you REALLY add 0x6c,
and then you cast the result back to int *.

That's C ... the other solutions suggested (templates etc.) are C++
and don't apply in your case.

HTH, kind regards

Bernd



Am 08.02.2018 um 17:45 schrieb Barkow, Eileen:
Thank you Charles and Seymore. I thought that the problem had 
something to do with adding to pointers but

I could not find any doc about it in the manuals.
I am still not sure that I understand how to fix it but I will try 
based on your info.





--
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: [EXTERNAL] Re: Delete dataset catch-22

[Dyck, Lionel B. (TRA)]

Have you considered using IEHPROGM ?


--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Thursday, February 08, 2018 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Delete dataset catch-22

Yes, I did specify FILE


 *DELETE MARPACE.GODADDY.CERT FILE(DD1) *

IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 102 - REASON CODE IS IGG0CLFM-2 
IDC0551I ** ENTRY MARPACE.GODADDY.CERT NOT DELETED IDC0001I FUNCTION COMPLETED, 
HIGHEST CONDITION CODE WAS 8

On Thu, Feb 8, 2018 at 2:45 PM, Andrew Arentsen 
wrote:

> Did you specify the FILE when using IDCAMS DEL NVR?
>
>
> //
> //* DELETES NON-CATALOGED DATASETS WITH IDCAMS
> //* USE VVR FOR VSAM DATASETS
> //* USE NVR FOR SAM DATASETS
> //* CHANGE VOLSER TO MATCH VOLUME THAT DATASET RESIDES ON
> //
> //STEP1 EXEC PGM=IDCAMS
> //SYSPRINT DD SYSOUT=*
> //FILE2 DD UNIT=SYSDA,VOL=SER=TSO901,DISP=OLD
> //SYSIN DD *
>   DEL ('DSZZ005.STT00035.VIALOG') NVR FILE(FILE2)
>
>
> Andrew Arentsen
> Senior Mainframe Systems Engineer
>
>
>
>
> From:   "Mark Pace" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   2018-02-08 13:39
> Subject:Delete dataset catch-22
> Sent by:"IBM Mainframe Discussion List" 
>
>
>
> I'm trying to delete a dataset that is not cataloged any longer.  I'm 
> not sure why it is not in a catalog, but it is not.  I've tried to 
> re-catalog the dataset, but it doesn't catalog.
>
> So I have tried to every combination of IDCAMS DELETE I can think of.
> NONVSAM
> NVR
> etc..
>
> All return
> ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - 
> Dataset not found.
>
> So I tried IEHPROGM
>   SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE
>
> IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E), 
> STEP010,STDL09,MARPACE.GODADDY.CERT
>
> 0406001E -  Verification of SMS flags failed; caller indicates the 
> data set is not cataloged, but the *FMT1 DSCB indicates the data set 
> is cataloged*
>
> So I have no idea how to remove this dataset, IDCAMS won't do it 
> because it's not in a catalog, and IEHPROGM won't do it because it 
> thinks it is in a catalog.
>
> Anyone have a suggestion?
>
> Thank you.
>
>
>
> --
> 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
>
>
>
>
> **
> This e-mail is confidential. If you are not the intended recipient, 
> you must not disclose or use the information contained in it. If you 
> have received this e-mail in error, please tell us immediately by 
> return e-mail and delete the document.
>
>
> --
> 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

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

Re: Delete dataset catch-22

[Andrew Arentsen]

Did you specify the FILE when using IDCAMS DEL NVR?


//
//* DELETES NON-CATALOGED DATASETS WITH IDCAMS 
//* USE VVR FOR VSAM DATASETS 
//* USE NVR FOR SAM DATASETS 
//* CHANGE VOLSER TO MATCH VOLUME THAT DATASET RESIDES ON 
//
//STEP1 EXEC PGM=IDCAMS 
//SYSPRINT DD SYSOUT=* 
//FILE2 DD UNIT=SYSDA,VOL=SER=TSO901,DISP=OLD 
//SYSIN DD * 
  DEL ('DSZZ005.STT00035.VIALOG') NVR FILE(FILE2) 


Andrew Arentsen
Senior Mainframe Systems Engineer




From:   "Mark Pace" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   2018-02-08 13:39
Subject:Delete dataset catch-22
Sent by:"IBM Mainframe Discussion List" 



I'm trying to delete a dataset that is not cataloged any longer.  I'm not
sure why it is not in a catalog, but it is not.  I've tried to re-catalog
the dataset, but it doesn't catalog.

So I have tried to every combination of IDCAMS DELETE I can think of.
NONVSAM
NVR
etc..

All return
** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - Dataset
not found.

So I tried IEHPROGM
  SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE

IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E),
STEP010,STDL09,MARPACE.GODADDY.CERT

0406001E -  Verification of SMS flags failed; caller indicates the data 
set
is not cataloged, but the *FMT1 DSCB indicates the data set is cataloged*

So I have no idea how to remove this dataset, IDCAMS won't do it because
it's not in a catalog, and IEHPROGM won't do it because it thinks it is in
a catalog.

Anyone have a suggestion?

Thank you.



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




**
This e-mail is confidential. If you are not the intended recipient, you must 
not disclose or use the information contained in it. If you have received this 
e-mail in error, please tell us immediately by return e-mail and delete the 
document.


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

Re: Best Practices for z/OS Maintenance

[Seymour J Metz]

SMP should not be pointing at the live Unix directories. The real question is 
how to merge  new/changed files in the target file system with production 
files, whether in /etc and /var or elsewhere.


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


From: IBM Mainframe Discussion List  on behalf of 
Dyck, Lionel B. (TRA) 
Sent: Thursday, February 8, 2018 2:36 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Best Practices for z/OS Maintenance

A question was asked what the best practices are for installing z/OS 
maintenance to make sure that the /etc and /var files are not replaced by IBM 
maintenance?

(cross posting to MVS OpenEdition and IBM-Main Listservs)

Thank you

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


--
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: Silly C problem adding hex 6C

[Bernd Oppolzer]

int  *ASCB;
int  *ASXB;
ASXB = ASCB + 0x6c;

because ASCB is a pointer to int, and int has sizeof = 4,
you are in fact adding 4 * 0x6c to ASCB, that's your problem.

use the following notation, and it will work:

ASXB = (int *) ((char *) ASCB + 0x6c);

first you cast the ASCB to a char *, then you REALLY add 0x6c,
and then you cast the result back to int *.

That's C ... the other solutions suggested (templates etc.) are C++
and don't apply in your case.

HTH, kind regards

Bernd



Am 08.02.2018 um 17:45 schrieb Barkow, Eileen:

Thank you Charles and Seymore. I thought that the problem had something to do 
with adding to pointers but
I could not find any doc about it in the manuals.
I am still not sure that I understand how to fix it but I will try based on 
your info.




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

Re: [EXTERNAL] Re: Delete dataset catch-22

[Brown, Duncan]

Or a BR14?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Thursday, February 08, 2018 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Delete dataset catch-22

Have you considered using IEHPROGM ?


--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Thursday, February 08, 2018 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Delete dataset catch-22

Yes, I did specify FILE


 *DELETE MARPACE.GODADDY.CERT FILE(DD1) *

IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 102 - REASON CODE IS IGG0CLFM-2 
IDC0551I ** ENTRY MARPACE.GODADDY.CERT NOT DELETED IDC0001I FUNCTION COMPLETED, 
HIGHEST CONDITION CODE WAS 8

On Thu, Feb 8, 2018 at 2:45 PM, Andrew Arentsen 
wrote:

> Did you specify the FILE when using IDCAMS DEL NVR?
>
>
> //
> //* DELETES NON-CATALOGED DATASETS WITH IDCAMS
> //* USE VVR FOR VSAM DATASETS
> //* USE NVR FOR SAM DATASETS
> //* CHANGE VOLSER TO MATCH VOLUME THAT DATASET RESIDES ON
> //
> //STEP1 EXEC PGM=IDCAMS
> //SYSPRINT DD SYSOUT=*
> //FILE2 DD UNIT=SYSDA,VOL=SER=TSO901,DISP=OLD
> //SYSIN DD *
>   DEL ('DSZZ005.STT00035.VIALOG') NVR FILE(FILE2)
>
>
> Andrew Arentsen
> Senior Mainframe Systems Engineer
>
>
>
>
> From:   "Mark Pace" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   2018-02-08 13:39
> Subject:Delete dataset catch-22
> Sent by:"IBM Mainframe Discussion List" 
>
>
>
> I'm trying to delete a dataset that is not cataloged any longer.  I'm 
> not sure why it is not in a catalog, but it is not.  I've tried to 
> re-catalog the dataset, but it doesn't catalog.
>
> So I have tried to every combination of IDCAMS DELETE I can think of.
> NONVSAM
> NVR
> etc..
>
> All return
> ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - 
> Dataset not found.
>
> So I tried IEHPROGM
>   SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE
>
> IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E), 
> STEP010,STDL09,MARPACE.GODADDY.CERT
>
> 0406001E -  Verification of SMS flags failed; caller indicates the 
> data set is not cataloged, but the *FMT1 DSCB indicates the data set 
> is cataloged*
>
> So I have no idea how to remove this dataset, IDCAMS won't do it 
> because it's not in a catalog, and IEHPROGM won't do it because it 
> thinks it is in a catalog.
>
> Anyone have a suggestion?
>
> Thank you.
>
>
>
> --
> 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
>
>
>
>
> **
> This e-mail is confidential. If you are not the intended recipient, 
> you must not disclose or use the information contained in it. If you 
> have received this e-mail in error, please tell us immediately by 
> return e-mail and delete the document.
>
>
> --
> 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

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


-
CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends 
this e-mail message, and any attachments, to be used only by the person(s) or 
entity to which it is addressed. This message may contain confidential and/or 
legally privileged information. If the reader is not the intended recipient of 
this message or an employee or agent responsible for delivering the message to 
the intended recipient, you are hereby notified that you are prohibited from 
printing, copying, storing, disseminating or distributing this communication. 
If you 

Best Practices for z/OS Maintenance

[Dyck, Lionel B. (TRA)]

A question was asked what the best practices are for installing z/OS 
maintenance to make sure that the /etc and /var files are not replaced by IBM 
maintenance?

(cross posting to MVS OpenEdition and IBM-Main Listservs)

Thank you

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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

Re: Delete dataset catch-22

[John McKown]

On Thu, Feb 8, 2018 at 1:38 PM, Mark Pace  wrote:

> I'm trying to delete a dataset that is not cataloged any longer.  I'm not
> sure why it is not in a catalog, but it is not.  I've tried to re-catalog
> the dataset, but it doesn't catalog.
>
> So I have tried to every combination of IDCAMS DELETE I can think of.
> NONVSAM
> NVR
> etc..
>

​Are you saying that you have done the following and it failed?

//DELETE EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
 DELETE SOME.DSN NVR FILE(VOLUME)
/*
//VOLUME DD DISP=OLD,UNIT=SYSALLDA,VOL=SER=volume
​
​That has always worked for me. That's for a nonVSAM data set on "volume".​



>
> All return
> ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - Dataset
> not found.
>
> So I tried IEHPROGM
>   SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE
>
> IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E),
> STEP010,STDL09,MARPACE.GODADDY.CERT
>
> 0406001E -  Verification of SMS flags failed; caller indicates the data set
> is not cataloged, but the *FMT1 DSCB indicates the data set is cataloged*
>
> So I have no idea how to remove this dataset, IDCAMS won't do it because
> it's not in a catalog, and IEHPROGM won't do it because it thinks it is in
> a catalog.
>
> Anyone have a suggestion?
>
> Thank you.
>
>
>
> --
> 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
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Delete dataset catch-22

[Mark Pace]

I'm trying to delete a dataset that is not cataloged any longer.  I'm not
sure why it is not in a catalog, but it is not.  I've tried to re-catalog
the dataset, but it doesn't catalog.

So I have tried to every combination of IDCAMS DELETE I can think of.
NONVSAM
NVR
etc..

All return
** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - Dataset
not found.

So I tried IEHPROGM
  SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE

IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E),
STEP010,STDL09,MARPACE.GODADDY.CERT

0406001E -  Verification of SMS flags failed; caller indicates the data set
is not cataloged, but the *FMT1 DSCB indicates the data set is cataloged*

So I have no idea how to remove this dataset, IDCAMS won't do it because
it's not in a catalog, and IEHPROGM won't do it because it thinks it is in
a catalog.

Anyone have a suggestion?

Thank you.



-- 
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: Delete dataset catch-22

[Allan Staller]

Please post the results from idcams DEF RECATALOG.
I have seen *VERY FEW* cases that could not be resolved via some combination of 
DEF RECATALOG, DEL NSCR, DEL VVR, DEL NVR.

HTH,

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Thursday, February 8, 2018 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Delete dataset catch-22

I'm trying to delete a dataset that is not cataloged any longer.  I'm not sure 
why it is not in a catalog, but it is not.  I've tried to re-catalog the 
dataset, but it doesn't catalog.

So I have tried to every combination of IDCAMS DELETE I can think of.
NONVSAM
NVR
etc..

All return
** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - Dataset not 
found.

So I tried IEHPROGM
  SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE

IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E), 
STEP010,STDL09,MARPACE.GODADDY.CERT

0406001E -  Verification of SMS flags failed; caller indicates the data set is 
not cataloged, but the *FMT1 DSCB indicates the data set is cataloged*

So I have no idea how to remove this dataset, IDCAMS won't do it because it's 
not in a catalog, and IEHPROGM won't do it because it thinks it is in a catalog.

Anyone have a suggestion?

Thank you.



--
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
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Delete dataset catch-22

[Mark Pace]

Doing the define NONVSAM - got me a little closer - the dataset is now
cataloged.  But when I use D to delete the datset -

IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (04060020),
IKJACCNT,STDL09,MARPACE.GODADDY.CERT

04060020 -  Verification of SMS flags failed; caller indicates data set is
not SMS-managed, but FMT4 DSCB indicates that it is an SMS volume. This
error might be caused by a damaged catalog entry. Issuing the recatalog
command might clear this error.

Do I will try the recatalog command.

On Thu, Feb 8, 2018 at 2:44 PM, Burrell, Todd  wrote:

> What do you get if you try this in IDCAMS:
>
>   DEFINE NONVSAM(NAME(MARPACE.GODADDY.CERT) -
>  DEVT(3390) VOLUME(STDL09))
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Pace
> Sent: Thursday, February 08, 2018 2:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Delete dataset catch-22
>
> I'm trying to delete a dataset that is not cataloged any longer.  I'm not
> sure why it is not in a catalog, but it is not.  I've tried to re-catalog
> the dataset, but it doesn't catalog.
>
> So I have tried to every combination of IDCAMS DELETE I can think of.
> NONVSAM
> NVR
> etc..
>
> All return
> ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - Dataset
> not found.
>
> So I tried IEHPROGM
>   SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE
>
> IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E),
> STEP010,STDL09,MARPACE.GODADDY.CERT
>
> 0406001E -  Verification of SMS flags failed; caller indicates the data
> set is not cataloged, but the *FMT1 DSCB indicates the data set is
> cataloged*
>
> So I have no idea how to remove this dataset, IDCAMS won't do it because
> it's not in a catalog, and IEHPROGM won't do it because it thinks it is in
> a catalog.
>
> Anyone have a suggestion?
>
> Thank you.
>
>
>
> --
> 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
>
>
>
> This email transmission and any accompanying attachments may contain CSX
> privileged and confidential information intended only for the use of the
> intended addressee. Any dissemination, distribution, copying or action
> taken in reliance on the contents of this email by anyone other than the
> intended recipient is strictly prohibited. If you have received this email
> in error please immediately delete it and notify sender at the above CSX
> email address. Sender and CSX accept no liability for any damage caused
> directly or indirectly by receipt of this email.
>
>
> --
> 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: Delete dataset catch-22

[Mark Pace]

Yes, I did specify FILE


 *DELETE MARPACE.GODADDY.CERT FILE(DD1) *

IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 102 - REASON CODE IS IGG0CLFM-2
IDC0551I ** ENTRY MARPACE.GODADDY.CERT NOT DELETED
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8

On Thu, Feb 8, 2018 at 2:45 PM, Andrew Arentsen 
wrote:

> Did you specify the FILE when using IDCAMS DEL NVR?
>
>
> //
> //* DELETES NON-CATALOGED DATASETS WITH IDCAMS
> //* USE VVR FOR VSAM DATASETS
> //* USE NVR FOR SAM DATASETS
> //* CHANGE VOLSER TO MATCH VOLUME THAT DATASET RESIDES ON
> //
> //STEP1 EXEC PGM=IDCAMS
> //SYSPRINT DD SYSOUT=*
> //FILE2 DD UNIT=SYSDA,VOL=SER=TSO901,DISP=OLD
> //SYSIN DD *
>   DEL ('DSZZ005.STT00035.VIALOG') NVR FILE(FILE2)
>
>
> Andrew Arentsen
> Senior Mainframe Systems Engineer
>
>
>
>
> From:   "Mark Pace" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   2018-02-08 13:39
> Subject:Delete dataset catch-22
> Sent by:"IBM Mainframe Discussion List" 
>
>
>
> I'm trying to delete a dataset that is not cataloged any longer.  I'm not
> sure why it is not in a catalog, but it is not.  I've tried to re-catalog
> the dataset, but it doesn't catalog.
>
> So I have tried to every combination of IDCAMS DELETE I can think of.
> NONVSAM
> NVR
> etc..
>
> All return
> ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - Dataset
> not found.
>
> So I tried IEHPROGM
>   SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE
>
> IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E),
> STEP010,STDL09,MARPACE.GODADDY.CERT
>
> 0406001E -  Verification of SMS flags failed; caller indicates the data
> set
> is not cataloged, but the *FMT1 DSCB indicates the data set is cataloged*
>
> So I have no idea how to remove this dataset, IDCAMS won't do it because
> it's not in a catalog, and IEHPROGM won't do it because it thinks it is in
> a catalog.
>
> Anyone have a suggestion?
>
> Thank you.
>
>
>
> --
> 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
>
>
>
>
> **
> This e-mail is confidential. If you are not the intended recipient, you
> must not disclose or use the information contained in it. If you have
> received this e-mail in error, please tell us immediately by return e-mail
> and delete the document.
>
>
> --
> 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: Delete dataset catch-22

[Mark Pace]

The
DEFINE NONVSAM(NAME(MARPACE.GODADDY.CERT) -
 DEVT(3390) VOLUME(STDL09))
got it cataloged again, but I still could not delete the file.

So I did
DELETE  MARPACE.GODADDY.CERT   NOSCRATCH
to get it removed from the catalog again.

Then did a
DEFINE NONVSAM -
 (NAME(MARPACE.GODADDY.CERT) -
  DEVICETYPE(3390) -
  VOLUMES(STDL09) -
  RECATALOG)

This time I was able to us D to delete the file from PDF.

Thanks to all for the suggestions.

On Thu, Feb 8, 2018 at 3:05 PM, Mark Pace  wrote:

> Yes, I did specify FILE
>
>
>  *DELETE MARPACE.GODADDY.CERT FILE(DD1) *
>
> IDC3014I CATALOG ERROR
>
> IDC3009I ** VSAM CATALOG RETURN CODE IS 102 - REASON CODE IS IGG0CLFM-2
> IDC0551I ** ENTRY MARPACE.GODADDY.CERT NOT DELETED
>
> IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8
>
> On Thu, Feb 8, 2018 at 2:45 PM, Andrew Arentsen <
> andrew.arent...@acuity.com> wrote:
>
>> Did you specify the FILE when using IDCAMS DEL NVR?
>>
>>
>> //
>> //* DELETES NON-CATALOGED DATASETS WITH IDCAMS
>> //* USE VVR FOR VSAM DATASETS
>> //* USE NVR FOR SAM DATASETS
>> //* CHANGE VOLSER TO MATCH VOLUME THAT DATASET RESIDES ON
>> //
>> //STEP1 EXEC PGM=IDCAMS
>> //SYSPRINT DD SYSOUT=*
>> //FILE2 DD UNIT=SYSDA,VOL=SER=TSO901,DISP=OLD
>> //SYSIN DD *
>>   DEL ('DSZZ005.STT00035.VIALOG') NVR FILE(FILE2)
>>
>>
>> Andrew Arentsen
>> Senior Mainframe Systems Engineer
>>
>>
>>
>>
>> From:   "Mark Pace" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date:   2018-02-08 13:39
>> Subject:Delete dataset catch-22
>> Sent by:"IBM Mainframe Discussion List" > >
>>
>>
>>
>> I'm trying to delete a dataset that is not cataloged any longer.  I'm not
>> sure why it is not in a catalog, but it is not.  I've tried to re-catalog
>> the dataset, but it doesn't catalog.
>>
>> So I have tried to every combination of IDCAMS DELETE I can think of.
>> NONVSAM
>> NVR
>> etc..
>>
>> All return
>> ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - Dataset
>> not found.
>>
>> So I tried IEHPROGM
>>   SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE
>>
>> IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E),
>> STEP010,STDL09,MARPACE.GODADDY.CERT
>>
>> 0406001E -  Verification of SMS flags failed; caller indicates the data
>> set
>> is not cataloged, but the *FMT1 DSCB indicates the data set is cataloged*
>>
>> So I have no idea how to remove this dataset, IDCAMS won't do it because
>> it's not in a catalog, and IEHPROGM won't do it because it thinks it is in
>> a catalog.
>>
>> Anyone have a suggestion?
>>
>> Thank you.
>>
>>
>>
>> --
>> 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
>>
>>
>>
>>
>> **
>> This e-mail is confidential. If you are not the intended recipient, you
>> must not disclose or use the information contained in it. If you have
>> received this e-mail in error, please tell us immediately by return e-mail
>> and delete the document.
>>
>>
>> --
>> 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
>
>
>
>


-- 
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: Silly C problem adding hex 6C

[Barkow, Eileen]

Thank you John, Charles, Seymour, Allan,Paul and everyone else for their help 
with this.
I finally got the program to work and display the job name. Of course there are 
more efficient ways of coding this using struct and templates,
but this is the way I can best understand the strange workings of this somewhat 
convoluted compiler.

$ jn2
ASCB = FB7A00
ASXBC =  FB7A6C
ASXB =  FB7A6C
ASXBP = AFD000
JNP = AFD0C0
jobname = ACSCEXB

jn2.c

define _XOPEN_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
int main(int argc, char *argv[])
 {
int *PSA;
int  *ASCB;
int  *ASXB=nullptr;
unsigned char *ASXBC;
unsigned char *JNPC;
int   *   ASXBP;
int   *   JNPI;
unsigned char jobname[9];
unsigned char * JNP;
PSA=(int *)0x224; /* address of PSAAOLD */
ASCB=(int *)*PSA;
printf("ASCB = %X\n",ASCB);
ASXBC= (unsigned char *)ASCB + 0x6c;
printf("ASXBC =  %X\n",ASXBC);
ASXB= (int *)ASXBC;
printf("ASXB =  %X\n",ASXB);
ASXBP = (int *)*ASXB;
printf("ASXBP = %X\n",ASXBP);
JNP = (unsigned char *)ASXBP+0XC0;
printf("JNP = %X\n",JNP);
JNPI = (int *)JNP;
memcpy  (jobname,JNPI,8);
cout<<"jobname = "< wrote:

> On Thu, 8 Feb 2018 10:22:40 -0600, Allan Kielstra wrote:
>
> >The size of a char in 1 byte.  Try
> >
> >(char *) ASXB = (char *) ASCB + 0x6c;  /* lazy version */
> >
> ANSI says a cast may not be used as an L-value.  IBM's C compiler
> enforces this.  I once did something like (IIRC?):
> *(char * *) ASXB += 0x6c;
>

​I did it this way:

char *psaaold;
char *ascbjbni;
unsigned char *ascbjbns;
unsigned char *ascbjbn;
unsigned char *a;
unsigned char jobname[9];
psaaold = *(unsigned char **)0x224; /* address of PSAAOLD */
ascbjbni = *(unsigned char **)(psaaold + 0xac);
ascbjbns = *(unsigned char **)(psaaold + 0xb0);​



>
> My head hurts.
>
> -- gil
>


--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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




This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.

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

Re: Best Practices for z/OS Maintenance

[Jesse 1 Robinson]

For us, both /etc and /var live their own respective file systems that are not 
touched by standard migration from SMPE install to prod. Hence there's no 
danger of overlaying installation values. OTOH, as Shmuel says, the problem is 
how to propagate an updated install value into production. First of all it 
would have to be a manual process, but how to know when/whether to perform such 
an update? I can't suggest an algorithmic way to do this, but I'm not an OMVS 
whiz by any means.  

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Thursday, February 08, 2018 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Best Practices for z/OS Maintenance

SMP should not be pointing at the live Unix directories. The real question is 
how to merge  new/changed files in the target file system with production 
files, whether in /etc and /var or elsewhere.


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


From: IBM Mainframe Discussion List  on behalf of 
Dyck, Lionel B. (TRA) 
Sent: Thursday, February 8, 2018 2:36 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Best Practices for z/OS Maintenance

A question was asked what the best practices are for installing z/OS 
maintenance to make sure that the /etc and /var files are not replaced by IBM 
maintenance?

(cross posting to MVS OpenEdition and IBM-Main Listservs)

Thank you

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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

Re: codepages

[zMan]

"mage the pages"?

On Thu, Feb 8, 2018 at 11:15 AM, Seymour J Metz  wrote:

> Why do you need windowing? What you need is to mage the pages, and the
> same issues exist whether the mapping is windowed or direct into virtual
> memory.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Tony Harminc 
> Sent: Wednesday, February 7, 2018 6:20 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: codepages
>
> On 6 February 2018 at 14:17, Peter Hunkeler  wrote:
> >> Isn't this what DIV is for?
> >
> > DIV works with VSAM linear data sets. How would it help here?
>
> The discussion has been (mostly) about loading an entire dataset into
> virtual storage (as ISPF Edit does) vs windowing techniques that avoid
> requiring a huge amount of virtual.
>
> I wasn't suggesting that DIV could apply directly to (say) a PS or PO
> dataset, but if you want to implement windowing you need some scheme
> to map file data to a smaller amount of virtual storage. DIV would
> seem to be a base to build on.
>
> Tony H.
>
> --
> 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: Best Practices for z/OS Maintenance

[Tom Conley]

On 2/8/2018 3:22 PM, Seymour J Metz wrote:

SMP should not be pointing at the live Unix directories. The real question is 
how to merge  new/changed files in the target file system with production 
files, whether in /etc and /var or elsewhere.


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


From: IBM Mainframe Discussion List  on behalf of Dyck, 
Lionel B. (TRA) 
Sent: Thursday, February 8, 2018 2:36 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Best Practices for z/OS Maintenance

A question was asked what the best practices are for installing z/OS 
maintenance to make sure that the /etc and /var files are not replaced by IBM 
maintenance?

(cross posting to MVS OpenEdition and IBM-Main Listservs)

Thank you



I'm covering that in my Advanced SMP/E session at zTechU in Orlando and 
London, if IBM accepts the sessions.


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: FICON PTP CTC & GDPS

[Vince Getgood]

Thanks.
It's Not my decision...

I'll definitely be testing.  We have two directors, and I'll be removing one at 
a time...

I'd still like someone to confirm what I want to do is even possible...

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

Re: So long and thanks for all the fish

[Elardus Engelbrecht]

Mark Jacobs wrote:

>Sometime this year all existing mainframe processes will be moved to another 
>fulfillment house(non-mainframe) for Time Inc (now Meredith Corporation) and 
>Time Customer Service will be shut down. It's been a great 22.5 years here for 
>me, I might make it to 23 in August before I'm terminated. After that happens, 
>who knows what the future brings.

Ouch, seemed things have Time Out for you... 

(similar to the other IBM-MAIN member whose company is trying to 
'get-off-the-mainframe' for how many years...)

We will miss you, your wisdom and your posts. All of the very best to you and 
your family.

I really hope you can get another work in time. Please keep us updated if you 
can.

Good luck.

Groete / Greetings
Elardus Engelbrecht

Thursday - this day is actually called "Friday Beta Version". ;-)

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

Re: Silly C problem adding hex 6C

[Elardus Engelbrecht]

Bernd Oppolzer wrote:

>To be more pedantic, use additional parantheses:
>ASXB = (int *) (((char *) ASCB) + 0x6c);

I C ( "I see"   ;-D )

Seriously, I find this whole thread very interesting.

Just a question please and please excuse my ignorance. 

Are these discussions about C or C++?

Because:

OP said 'crawl my way around C/C++'
Shmuel and Paul are talking about C and Charles talked about C++ (for his 2 
templates)

Feel free to teach me so I can C...

TIA!

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

AW: Delete dataset catch-22

[Werner Kuehnel]

Mark,
try this, it worked for me to delete uncataloged SMS managed datasets:

//STEP1  EXEC  PGM=ADRDSSU,PARM='LINECNT=72' 
//SYSPRINT DD  SYSOUT=*  
//V1   DD  DISP=SHR,UNIT=3390,VOL=SER=?? 
//AUS1 DD  DUMMY 
//SYSINDD  * 
 DUMP  - 
 INDD(V1)  - 
 OUTDD(AUS1)   - 
 DATASET(INCLUDE(**)   - 
 BY(CATLG,EQ,0))   - 
 DELETE- 
 ADMIN - 
 PURGE   


Werner Kuehnel

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Mark Pace
Gesendet: Donnerstag, 8. Februar 2018 20:38
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Delete dataset catch-22

I'm trying to delete a dataset that is not cataloged any longer.  I'm not sure 
why it is not in a catalog, but it is not.  I've tried to re-catalog the 
dataset, but it doesn't catalog.

So I have tried to every combination of IDCAMS DELETE I can think of.
NONVSAM
NVR
etc..

All return
** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42  - Dataset not 
found.

So I tried IEHPROGM
  SCRATCH DSNAME=MARPACE.GODADDY.CERT,VOL=3390=STDL09,PURGE

IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0406001E), 
STEP010,STDL09,MARPACE.GODADDY.CERT

0406001E -  Verification of SMS flags failed; caller indicates the data set is 
not cataloged, but the *FMT1 DSCB indicates the data set is cataloged*

So I have no idea how to remove this dataset, IDCAMS won't do it because it's 
not in a catalog, and IEHPROGM won't do it because it thinks it is in a catalog.

Anyone have a suggestion?

Thank you.



--
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: [EXTERNAL] Re: Best Practices for z/OS Maintenance

[Craig Pace]

I always kept a SERVICE copy of the filesystems that were IBM related and then 
applied and that is what SMP/E pointed to.  Each shop usually has what works 
best for them, but below are the two main ways that I have done it.

1)  Less Work, but Less Control (from SMP/E that is if someone bypasses SMP/E).

Have a single set of RESVOLs, DLIBVOLs and USS Filesystem libraries that SMP/E 
points toward.  If you have a stand-along Tech LPAR or Sandbox, have the 
ability to IPL from this only for validation, but I try to keep this just for 
SMP/E only!

Share SYSRES and/or USS Filesystems where possible.  Makes life a lot easier 
with maintenance.

Have two copies per LPAR(s), that can be alternated between during IPLs.  A lot 
of maintenance can be applied live these days; however, there are still ones 
that still required an IPL.

Perform a DFDSS copy of the required volumes and filesystems from the SMP/E 
target to the LPAR(s) target.

For USS, all configuration files, etc. that are normally in /etc & /var are 
never overwritten by IBM.  The sample configuration files are what are updated 
and then you must apply those changes or merge your updates with the new 
samples, if required or needed.  I also use a Company level filesystem, where 
you can override the default path, as this makes upgrades even easier.  Most of 
the items that you put in /etc & /var can be overridden by parameters passed 
during execution or profile settings.

2)  More Work/More SMP/E Control

Have a Tech set of SMP/E SYSRES, DLIB and USS Filesystems.  Applied all initial 
maintenance (RECEIVE, APPLY, ACCEPT) to this as normal processing

Have a separate SMP/E SYSRES, DLIB and USS Filesystems per shared (or single) 
environment.  Once maintenance is validated within the Tech environment, you 
can run SMP/E compares between the Tech and next environment to dynamically 
create the required SMP/E input statement to APPLY and/or ACCEPT as needed.

For USS, same concept as the first method.

The trick is to simply the process as much as possible without loosing control. 
 The smaller the support team, the less SMP/E management you can allow.  If you 
have people that don't follow the rules or too large (multiple teams, etc.) 
Allowing more control by SMP/E can save you a lot of headache with keeping 
things in sync.



Thanks,


Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Thursday, February 8, 2018 21:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Best Practices for z/OS Maintenance

On 2/8/2018 3:22 PM, Seymour J Metz wrote:
> SMP should not be pointing at the live Unix directories. The real question is 
> how to merge  new/changed files in the target file system with production 
> files, whether in /etc and /var or elsewhere.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gm
> u.edu%2F~smetz3=02%7C01%7CCraig.Pace%40FOTLINC.COM%7Cf70440474759
> 4fd459a508d56f6a2a02%7C899afa299b73498f8294e6528bc00a38%7C0%7C0%7C6365
> 37424132131227=NoTyURkvnydFn4sjbHcS0p%2F88l6ug%2BD1H47vbUUF%2By8
> %3D=0
>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Dyck, Lionel B. (TRA) 
> Sent: Thursday, February 8, 2018 2:36 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Best Practices for z/OS Maintenance
>
> A question was asked what the best practices are for installing z/OS 
> maintenance to make sure that the /etc and /var files are not replaced by IBM 
> maintenance?
>
> (cross posting to MVS OpenEdition and IBM-Main Listservs)
>
> Thank you
>

I'm covering that in my Advanced SMP/E session at zTechU in Orlando and London, 
if IBM accepts the sessions.

Regards,
Tom Conley

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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



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

Re: REXX say 'location:https://... in a batch job

[Lizette Koehler]

If you were not aware there is a REXX list that might also be helpful with this.

To join, if you have not done so, use this URL, bottom of webpage I think to 
sign up

TSO REXXhttp://www2.marist.edu/htbin/wlvindex?TSO-REXX


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mary Kay Tubello
> Sent: Thursday, February 08, 2018 7:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: REXX say 'location:https://... in a batch job
> 
> Hello,
> 
> I have two REXXs in USS on z/OS that I execute from a URL.  The ‘say’ re-
> directs to a website.   Is it possible to execute these in a batch job?  And
> if yes,  how will I know they worked?
> 
>  Thanks,
> Mary Kay
> 
> 1. This url:https://mvs.humana.com/HUMcgi/url1.sh
> executes this REXX to point to another mainframe webserver.
> 
> /*  REXX  */
> /**
> /* This is code for transferring to a web page.
> /*
> /* 02/07/18  this works!!
> /**
>  say 'location:https://syss.humana.com/perftune'
>  say
>  return 0
> 
> 
> 2. This url:   https://mvs.humana.com/HUMcgi/url.sh
> executes this REXX to go to a different server(non-mainframe)
> 
> /*  REXX  */
> /**/
> /* This is code for transferring to a web page.   */
> /*
> /*   02/07/18  This works!!   has to have return 0*/
> /**/
> 
>  say  'location:https://dev-odssvcs.humana.com/ods/dbflashlistener/?quer
> y=0=true'
>say
> return 0
> 
> --
> 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: SMF advice on additional logstreams

[Richards, Robert B.]

Allan,

At this time, I am not contemplating using NOTYPE on either of them. My 
original question was whether I should pull them out of DEFAULT or not due to 
the frequency in which they are created. Still...all comments appreciated.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Thursday, February 08, 2018 11:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF advice on additional logstreams

Not sure about SMF92, but SMF99 are "WLM decision records".

Yes they are large volume, but somewhat indispensable.

Generally when there is a WLM problem it is extremely difficult or impossible 
to reproduce.
If the SMF99's are not available "during the problem" it is virtually 
impossible to debug.

IMO, SMF99's should be recorded.  I know Cheryl Watson and others may disagree.

My USD $0.02 worth,

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Scott
Sent: Thursday, February 8, 2018 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF advice on additional logstreams

I have always thought of SMF92 and SMF99 as data of interest primarily for 
monitoring products - do you have them enabled because of ISV requirements?

If there is ISV software that needs to read this SMF data in real time (eg via 
IEFU8x) but there is no need for historical storage for these types, perhaps 
the vendor (or you) could create a simple IEFU8x to suppress these records from 
being hardened to MANx datasets or logstreams.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Thursday, February 8, 2018 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF advice on additional logstreams

It was recently noticed that SMF TYPES 92 and 99 are creating a very high 
percentage of our overall SMF records. Seems to coincide with the 
implementation of z/OS 2.2, but that is speculative at the moment.

Has anyone considered (or implemented) making one or both into their own 
logstream(s)?  What about TYPE 120s from WebSphere?

At present, I have DEFAULT, RMF, RACF and DB2 with the usual types.

Thanks in advance, for your viewpoint(s).

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
 Rocket Software, Inc. and subsidiaries ■ 77 
Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 
Contact Customer Support: 
https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=lUU8KyIIZ5UpJX6ypDL%2FvS6%2Fd21%2BHuYJaq8FhqZD%2Bf8%3D=0
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=XXMltfkhIrQuNXdspClQAO4JClJMSbbTSDYMCitv7ZA%3D=0
Privacy Policy - 
https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=yOfhey0%2BRjTNYEaeidsV%2BoT6WS3XCJXjDy6UHsZt0z0%3D=0


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. 

Re: Silly C problem adding hex 6C

[Barkow, Eileen]

Thank you Charles and Seymore. I thought that the problem had something to do 
with adding to pointers but
I could not find any doc about it in the manuals.
I am still not sure that I understand how to fix it but I will try based on 
your info.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, February 08, 2018 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

Yes, pointer arithmetic is scaled by the item size. Works kind of like a
subscript. If foo is an int* then foo+1 points to the next integer. (IOW
foo+4 if you think in assembler terms.)

The basic strategy is to cast it to a char* and then back.

If you would like, here are two template functions that will do the trick
you want to accomplish.

// Pointer absolute arithmetic
// This one matches if no explicit typename
template static inline T *PointerAdd(const T *ptr, const int
increment)
{
return (T *)( reinterpret_cast(ptr)+increment );
}

// This one matches if explicit typename
template static inline T *PointerAdd(const void *ptr, const
int increment)
{
return (T *)( reinterpret_cast(ptr)+increment );
}

How to use? Here is an example of adding an absolute length to a struct
pointer:

apfePtr = PointerAdd(apfePtr, apfePtr->apfelen);

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, February 8, 2018 8:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Silly C problem adding hex 6C

Isn't pointer arithmetic in C scaled by the item size?

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




This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.

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

Re: So long and thanks for all the fish

[Dana Mitchell]

On Thu, 8 Feb 2018 07:01:36 -0500, Mark Jacobs - Listserv 
 wrote:

>The new owners didn't want to be in the fulfillment business so they're moving 
>all Time Inc fulfillment activities to their current service provider.
>
>Mark Jacobs
>

Does Meredith use CDS for fulfillment?  CDS used to be a mainframe shop here in 
town,  they converted to IBM i years ago.   Meredith was also a good sized  
mainframe shop in the past too, but sadly no more.  Fewer and fewer local shops 
remain.

Good luck with your future endeavors!

Dana

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

REXX say 'location:https://... in a batch job

[Mary Kay Tubello]

Hello,

I have two REXXs in USS on z/OS that I execute from a URL.  The ‘say’ 
re-directs to a website.   Is it possible to execute these in a batch job?  And 
if yes,  how will I know they worked?

 Thanks,
Mary Kay

1. This url:https://mvs.humana.com/HUMcgi/url1.sh
executes this REXX to point to another mainframe webserver. 

/*  REXX  */   
/**
/* This is code for transferring to a web page.
/* 
/* 02/07/18  this works!!  
/**
 say 'location:https://syss.humana.com/perftune'   
 say   
 return 0   

   
2. This url:   https://mvs.humana.com/HUMcgi/url.sh
executes this REXX to go to a different server(non-mainframe)

/*  REXX  */
/**/
/* This is code for transferring to a web page.   */
/*  
/*   02/07/18  This works!!   has to have return 0*/
/**/
   
 say  'location:https://dev-odssvcs.humana.com/ods/dbflashlistener/?quer
y=0=true' 
   say  
return 0

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

Re: So long and thanks for all the fish

[Mark Jacobs - Listserv]

Yes on the CDS question.

Dana Mitchell
February 8, 2018 at 8:58 AM

Does Meredith use CDS for fulfillment? CDS used to be a mainframe shop here in 
town, they converted to IBM i years ago. Meredith was also a good sized 
mainframe shop in the past too, but sadly no more. Fewer and fewer local shops 
remain.

Good luck with your future endeavors!

Dana

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



Please be alert for any emails that may ask you for login information or 
directs you to login via a link. If you believe this message is a phish or 
aren't sure whether this message is trustworthy, please send the original 
message as an attachment to 
'phish...@meredith.com'.


--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


This electronic message, including any attachments, may contain proprietary, 
confidential or privileged information for the sole use of the intended 
recipient(s). You are hereby notified that any unauthorized disclosure, 
copying, distribution, or use of this message is prohibited. If you have 
received this message in error, please immediately notify the sender by reply 
e-mail and delete it.

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

Re: So long and thanks for all the fish

[Mark Jacobs - Listserv]

The new owners didn't want to be in the fulfillment business so they're moving 
all Time Inc fulfillment activities to their current service provider.

Mark Jacobs


Jackson, Rob
February 7, 2018 at 8:55 PM
That is a crying, damn shame. Inherently foolish and willfully ignorant, and I 
imagine subject to the supposition that they cannot find resources to support 
it in the future.

Good luck to you, Mark.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Wednesday, February 07, 2018 8:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: So long and thanks for all the fish

[External Email]

Sometime this year all existing mainframe processes will be moved to another 
fulfillment house(non-mainframe) for Time Inc (now Meredith Corporation) and 
Time Customer Service will be shut down. It's been a great 22.5 years here for 
me, I might make it to 23 in August before I'm terminated. After that happens, 
who knows what the future brings.
--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


This electronic message, including any attachments, may contain proprietary, 
confidential or privileged information for the sole use of the intended 
recipient(s). You are hereby notified that any unauthorized disclosure, 
copying, distribution, or use of this message is prohibited. If you have 
received this message in error, please immediately notify the sender by reply 
e-mail and delete it.

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

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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



Please be alert for any emails that may ask you for login information or 
directs you to login via a link. If you believe this message is a phish or 
aren't sure whether this message is trustworthy, please send the original 
message as an attachment to 
'phish...@meredith.com'.

Mark Jacobs - Listserv
February 7, 2018 at 8:29 PM
Sometime this year all existing mainframe processes will be moved to another 
fulfillment house(non-mainframe) for Time Inc (now Meredith Corporation) and 
Time Customer Service will be shut down. It's been a great 22.5 years here for 
me, I might make it to 23 in August before I'm terminated. After that happens, 
who knows what the future brings.

--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


This electronic message, including any attachments, may contain proprietary, 
confidential or privileged information for the sole use of the intended 
recipient(s). You are hereby notified that any unauthorized disclosure, 
copying, distribution, or use of this message is prohibited. If you have 
received this message in error, please immediately notify the sender by reply 
e-mail and delete it.

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

Re: REXX say 'location:https://... in a batch job

[Grinsell, Don]

You might consider executing curl in your rexx to obtain the data from the 
remote server.  You can do that in a batch job.  

--
 
Donald Grinsell, Systems Programmer
Enterprise Technology Services Bureau
SITSD/Montana Department of Administration
406.444.2983 (D)


"When they kick out your front door, how you gonna come?  With your hands on 
your head or on the trigger of your gun?"  
~ The Clash

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mary Kay Tubello
> Sent: Thursday, February 08, 2018 7:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: REXX say 'location:https://... in a batch job
> 
> Hello,
> 
> I have two REXXs in USS on z/OS that I execute from a URL.  The ‘say’ re-
> directs to a website.   Is it possible to execute these in a batch job?  And
> if yes,  how will I know they worked?
> 
>  Thanks,
> Mary Kay
> 
> 1. This url:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmvs.humana.c
> om%2FHUMcgi%2Furl1.sh=02%7C01%7Cdgrinsell%40MT.GOV%7C2075f0da4bcb49763b8
> a08d56efd5357%7C7310812d67f04445a8babaa08aeae2b1%7C0%7C1%7C636536956677281486
> =JWfe91dW06v%2FNYmG06eNsDaPyfkV%2BFzvXtkN4Ac1ElE%3D=0
> executes this REXX to point to another mainframe webserver.
> 
> /*  REXX  */
> /**
> /* This is code for transferring to a web page.
> /*
> /* 02/07/18  this works!!
> /**
>  say 'location:https://syss.humana.com/perftune'
>  say
>  return 0
> 
> 
> 2. This url:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmvs.humana.c
> om%2FHUMcgi%2Furl.sh=02%7C01%7Cdgrinsell%40MT.GOV%7C2075f0da4bcb49763b8a
> 08d56efd5357%7C7310812d67f04445a8babaa08aeae2b1%7C0%7C1%7C636536956677281486&
> sdata=UHp8vZ5VycVESJenCZEBI9qyUQuHuoxxk5cdknVpe3A%3D=0
> executes this REXX to go to a different server(non-mainframe)
> 
> /*  REXX  */
> /**/
> /* This is code for transferring to a web page.   */
> /*
> /*   02/07/18  This works!!   has to have return 0*/
> /**/
> 
>  say  'location:https://dev-odssvcs.humana.com/ods/dbflashlistener/?quer
> y=0=true'
>say
> return 0
> 
> --
> 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: So long and thanks for all the fish

[Jack J. Woehr]

On 2/8/2018 5:01 AM, Mark Jacobs - Listserv wrote:

The new owners didn't want to be in the fulfillment business so they're moving 
all Time Inc fulfillment activities to their current service provider



I've found Time Magazine unfulfilling for a number of years already ... :)


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: REXX say 'location:https://... in a batch job

[John McKown]

On Thu, Feb 8, 2018 at 8:07 AM, Mary Kay Tubello 
wrote:

> Hello,
>
> I have two REXXs in USS on z/OS that I execute from a URL.  The ‘say’
> re-directs to a website.   Is it possible to execute these in a batch job?
> And if yes,  how will I know they worked?
>

​Basically, assuming I understand your question, the answer is "no". But,
then, I don't really know exactly what you are wanting your batch job to
do. Historically, a person uses a web browser to contact a web server with
a URL​. The web server decodes this URL and displays a page of output.
That's the simplest case. In your case, the web server does the equivalent
of saying "Go ask George" (re-direct). So the web browser, without
interaction with the end user, goes to the re-directed web server, perhaps
with a different URL. This is what your example REXX is doing -- telling
the web browser software to "go ask George".

I think what you are wanting is a way for a step in a batch job to "invoke"
a REST service. Yes, you can write REXX to do this. But it is basically
doing "low level" sockets programming in REXX using REXX Sockets.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.hala001/ipapirxa.htm
This is not really for the faint of heart. You might find the following to
be of interest:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.izua700/IZUHPINFO_RESTServices.htm



>
>  Thanks,
> Mary Kay
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: REXX say 'location:https://... in a batch job

[Seymour J Metz]

Yes, but they won't do what you want. You'll see the output instead of passing 
it to a web browser.


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


From: IBM Mainframe Discussion List [IBM-MAIN@listserv.ua.edu] on behalf of 
Mary Kay Tubello [mtube...@humana.com]
Sent: Thursday, February 8, 2018 9:07 AM
To: IBM-MAIN@listserv.ua.edu
Subject: REXX say 'location:https://... in a batch job

Hello,

I have two REXXs in USS on z/OS that I execute from a URL.  The ‘say’ 
re-directs to a website.   Is it possible to execute these in a batch job?  And 
if yes,  how will I know they worked?

 Thanks,
Mary Kay

1. This url:
https://secure-web.cisco.com/15XLlB95l-itiIe6kLLtHrgkl9xj07VP_TWy6OStEWKxEt-Pe9hjuEn70KJt2BBtCg4w1oKSV01Cj3sHwnUTBnIPgppE_OH5W8nmP-g_wj4TCM6RtC6NK_JGn4bM_TDAP-rtf-3Ra26F5di2tnKW-zlp27SQY-9XXaoy2UpOy8PCGJKJnrvaX_5osRdL0EcMwXrXiSUp0_WYy7VQoJZJm77ezwIcuSuBFwONVCK3is6StdHxvXq6PM06lZYdRK1-NRtxQboTHErJb7_Fbt62qOeUf_3zjVFCpXJZHQlv6HNtvRexvbkg9c85mmqTqnwVj9rvVYY4j3fun2eEhGf9HwybW1in55ywsJdimoImdtjdAw3jqxpqqDdvvC38mpgm7_ud-ti7vunVCkxpScfMDWzmfUIEIkZt9YFhLmQj2Og5rHJAnwFU3n6hJO6_XAJNQ/https%3A%2F%2Fmvs.humana.com%2FHUMcgi%2Furl1.sh
executes this REXX to point to another mainframe webserver.

/*  REXX  */
/**
/* This is code for transferring to a web page.
/*
/* 02/07/18  this works!!
/**
 say 
'location:https://secure-web.cisco.com/1PDuHb2vEt-WmwTkknCKSF6ycPOh3asE7hPlK4aj7Go-FkFTrVLHbKGCkv-ckMVkknSGVwXpAZFa9mo8JM9MGFZ0s5DO8r5K1JsLpqLqOhXO61xqhNrCtoUKmaoj8Q5g8W6UBGKcwBQFIq1pFRptc2ejasWjiDymSedgPuC7UOT9nKFCvFXnme-ss54vrZn3z1tEcNUEvo-r92hoyCHCcNcVuKMLWttx5Ca7Lf1npZAIIHxavHXAbUfmj2IfFxtuzpuvQwN9Lbb0BIgjn4a-thBElWNtybhCXoalsk5GlNDLG7LphTJT0WZ-4NH1eIImRs_FwBhpgo9eCoFMIsFVYLbsTa03w4oLmGJeUIHOMe1HWlUZ61-v_mvtMvCnbOj8eIgnDyyuXkr1zbbbwpyogQUOCmwVm_A2_A8UT_2Jj-aRQf057Ko9iSrpi8IgmMSBU/https%3A%2F%2Fsyss.humana.com%2Fperftune'
 say
 return 0


2. This url:   
https://secure-web.cisco.com/1MfX9kPXga1dxfUM3STlSkZffB4mCPLOwtxa929Y8_d86ammP2DJaz8jOz5zf-Wl3-qMTtuLcLsoF7bVHdJ8XX2RVyxuQtNVRMGbnrh2HiiUOyzGztG3nQBmeLJDmI0ua8yEx0HmPuYe2J2yJc5PzzFU2a-mvBac5bgKfSdUavM8m2Nx3zh2ISnDnyDDFTQ7o-0ZAwZwCtE7EdpAcUCnwQ7KCY5QZt1x9i1bkgDP3QIJK6XYEdymHuyc56PbkPhSV_cjv2IX2TJSQiorXdZ4kqP60YzjPL4r-wGD4c8uGceNjz6Q2mv5LnTVYsZrUAUb7wPuSDJli1jJ3R4Aca8rFi2CX69lq50k6XHCNDj6MQ2yZOZlr_-q8IME60vhbFlfDJ_pZWjtlzbk0Nvodk8Swp5EAxgjRqMYIVabn1sAUqR_bnBMwHks8azCqTi7zfrx6/https%3A%2F%2Fmvs.humana.com%2FHUMcgi%2Furl.sh
executes this REXX to go to a different server(non-mainframe)

/*  REXX  */
/**/
/* This is code for transferring to a web page.   */
/*
/*   02/07/18  This works!!   has to have return 0*/
/**/

 say  
'location:https://secure-web.cisco.com/13jypwrgF4rV9oePQ7k1ap_dsG-7FuFDw7__XHJST7LrvVlSAyg91Asc7pgd8nwT8rb2nrjfbxBuQHCiTL2jZcMjxj6_RZN2cu2p44tam82NyJpykFYBhzLKBphO2IB8jnVE5pahyGfUK1LMuc9jl6jPJ_Q-TxnU7LCxKXMN0w4MyXItGavRIGo67m9zFUTe2zwscITYIsfNDejW1hgWXxMc21_ljGQIhdYtSTL--OKZtsmTlZXsS1XS3D6vxoPldlFMjva2nLyylt3Lgj4FejNpyE2RLUgcJWeJTBXv_YqeXNgyrD3gr-2hc-2aFF8JZZlDfXTozeHDEmGVHHbWt_KC_RoNiwbMV32GOoUH0MffjrYBxtNcEz4PbkVHykaUsw3BctbBbJmrM_3hdpcUeNDSJRd8XcxkE9Iynufbxq7_mUZIHvCA3F8QAsjkg1BW8/https%3A%2F%2Fdev-odssvcs.humana.com%2Fods%2Fdbflashlistener%2F%3Fquer
y=0=true'
   say
return 0

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