Re: SDSF Process

[Willy Jensen]

I strongly recommend that you use the SDSF/REXX API. Use the following as a 
model. The actual fields to use are described in the SDSF Users guide.

 isfsysname='**'  
 isfowner=''  
 isfprefix='' 
 call isfcalls 'ON'   
 call syscalls 'ON'   
  
 do 2  /* forever */  
   address SDSF "ISFEXEC DA"  
   if rc<>0 then exit msgrtn  
   do n=1 to jname.0  
 rec.n=left(jname.n,8),   
   left(jtype.n,8),   
   left(jobid.n,8),   
   left(ownerid.n,8)  
   end
   /*"execio" jname.0 "diskw output (stem rec.)" */   
   do n=1 to jname.0;say rec.n;end
   address syscall 'sleep 5'  
 end  
 return 0 
  
msgrtn:   
 if  isfmsg<>""  then  Say  "isfmsg  is:"  isfmsg 
 do  ix=1  to  isfmsg2.0  
   Say  "isfmsg2."ix  "is:"  isfmsg2.ix   
 end  
 return 0

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

Re: SDSF Process

[Seymour J Metz]

The Converter does symbol substitution for JCL.There is more flexibility for 
in-stream data.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 2, 2022 9:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF Process

On Thu, 3 Mar 2022 00:34:24 +, Sri h Kolusu wrote:
>
>You can schedule a job that runs SDSF in batch and then extracts the contents. 
>I assumed that your systems have SYSSYM=ALLOW  so that you can save the 
>results using the date and time.
>Something like this
>
>// EXPORT SYMLIST=*
>// SET CDATE=Y
>// SET CTIME=H
>/*   ...  SYSINI DD * generated here??
>//SORTOUT  DD DSN=,
>//DISP=(NEW,CATLG,DELETE),
>//SPACE=(CYL,(1,1),RLSE)
>
There are recurrent discussions here of the difficulty of embedding
DATE.TIME in a data set name because the initiator must issue
ENQs before the first EXEC.  Are the symbols above resolved by
the converter or the scheduler, avoiding this problem?

Also, is there a hazard that if the job runs at midnight (or any lesser
boundary) the date may be obtained before midnight; the time the
next day, resulting in a DATE.TIME almost 24 hours too small?

Rexx handles this right.  I suspect that JCL does not.


--
gil

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

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

Re: SDSF Process

[Sri h Kolusu]

>/*   ...  SYSINI DD * generated here??

No. /* (Slash followed asterisk does not generate SYSIN


>> Are the symbols above resolved by the converter or the scheduler, avoiding 
>> this problem?

I believe it is resolved by the interpreter/converter

>>Also, is there a hazard that if the job runs at midnight (or any lesser
boundary) the date may be obtained before midnight; the time the
next day, resulting in a DATE.TIME almost 24 hours too small?

If we schedule the job to run 1 min past (01,16,31,46) then we wouldn't have a 
problem.
So within 1 minute you would have 4 runs and within an hour you would have 240 
runs and within a day(24 hours) you would have 5,760 runs.

IMHO 15 second interval is too small and I am not sure what the final goal is 
as he would be creating thousands of dataset within a day. Someone has to look 
up and do some analysis.

>>Rexx handles this right.  I suspect that JCL does not.

I don't think we need REXX in here

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

Re: SDSF Process

[Paul Gilmartin]

On Thu, 3 Mar 2022 00:34:24 +, Sri h Kolusu wrote:
>
>You can schedule a job that runs SDSF in batch and then extracts the contents. 
>I assumed that your systems have SYSSYM=ALLOW  so that you can save the 
>results using the date and time.
>Something like this
>
>// EXPORT SYMLIST=*
>// SET CDATE=Y
>// SET CTIME=H
>/*   ...  SYSINI DD * generated here??
>//SORTOUT  DD DSN=,
>//DISP=(NEW,CATLG,DELETE),
>//SPACE=(CYL,(1,1),RLSE)
>
There are recurrent discussions here of the difficulty of embedding
DATE.TIME in a data set name because the initiator must issue
ENQs before the first EXEC.  Are the symbols above resolved by
the converter or the scheduler, avoiding this problem?

Also, is there a hazard that if the job runs at midnight (or any lesser
boundary) the date may be obtained before midnight; the time the
next day, resulting in a DATE.TIME almost 24 hours too small?

Rexx handles this right.  I suspect that JCL does not.


-- 
gil

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

Re: SDSF Process

[Sri h Kolusu]

Steely Mark,

You can schedule a job that runs SDSF in batch and then extracts the contents. 
I assumed that your systems have SYSSYM=ALLOW  so that you can save the results 
using the date and time.
Something like this

// EXPORT SYMLIST=*
// SET CDATE=Y
// SET CTIME=H
/*
//**
//* Run SDSF in batch to capture the output of jobs sorted on  *
//* cpu% in DA queue.  *
//* This will capture a max da list of  jobs.  *
//**
//RUNSDSF  EXEC PGM=SDSF,PARM='++,133'
//ISFOUT   DD DSN=&,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE),
//LRECL=134,RECFM=FBA,BLKSIZE=0,DSORG=PS
//SYSPRINT DD SYSOUT=*
//ISFINDD *
PRE **
OWNER *
DA
SORT CPU% D
END
/*
//**
//* Extract the jobs list after the sort is done on CPU %  *
//**
//EXTRJOBS EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=(OLD,PASS),DSN=&
//SORTOUT  DD DSN=,
//DISP=(NEW,CATLG,DELETE),
//SPACE=(CYL,(1,1),RLSE)
//SYSINDD *
  OPTION COPY
  INREC IFTHEN=(WHEN=GROUP,
   BEGIN=(83,4,CH,EQ,C'CPU%'),
 END=(08,8,CH,EQ,C' '),
PUSH=(135:ID=8))

  OUTFIL BUILD=(001,134),
  INCLUDE=(135,8,ZD,GT,1,AND,
   008,8,CH,GT,C' ')
/*

Thanks,
Kolusu


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

SDSF Process

[Steely.Mark]

I would like to be able to have SDSF perform a DA and sort CPU% D every 15 
seconds  and store it to a file.

Does anyone have a process that does something similar - batch, started task 
etc.

Thank You

*** Disclaimer ***
This communication (including all attachments) is solely for the use of the 
person to whom it is addressed and is a confidential AAA communication. If you 
are not the intended recipient, any use, distribution, printing, or copying is 
prohibited. If you received this email in error, please immediately delete it 
and notify the sender.

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

Re: PCHID WWPN report

[Mainframe Sysprog]

Thanks all. Until the email from Ed, I didn't really realize or spot there
was a pattern to the WWPN which included the PCHIDs. Using that convention
I was able to "produce" the WWPNs in excel and do some VLOOKUPS to cross
check. I am progressing fine now.

On Wed, Mar 2, 2022 at 11:02 PM Radoslaw Skorupka 
wrote:

> W dniu 02.03.2022 o 16:20, Mainframe Sysprog pisze:
> > GM Listers,
> >
> > I want to obtain the WWPN of all PCHIDS on a processor and want to know
> > what would be the fastest/easiest way to do that.
> >
> > The objective here is to do kind of an audit of what's connected to where
> > for a new configuration and cross check it with intended HW
> configuration.
> > I have the report from the switch which shows the WWPN to which is
> > connected to, so if I can somehow get a report from the CEC listing the
> > PCHID and its WWPN, I can cross check what's cabled up and what's not.
> >
> > Right now the way I do this is go into individual PCHIDS and do a problem
> > determination from the HMC.
> >
> > Any help or pointers would be much appreciated.
>
> I don't have solution , but I would look at HMC/SE capabilities.
>  From OS point of view you may not see all the PCHIDs.
> Another source would be FC switch, but only for channels which are
> attached to given fabric.
>
> Hints:
> WWNN is constant for all ports
> WWPN is consecutive for consecutive PCHIDs.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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: PCHID WWPN report

[Radoslaw Skorupka]

W dniu 02.03.2022 o 16:20, Mainframe Sysprog pisze:

GM Listers,

I want to obtain the WWPN of all PCHIDS on a processor and want to know
what would be the fastest/easiest way to do that.

The objective here is to do kind of an audit of what's connected to where
for a new configuration and cross check it with intended HW configuration.
I have the report from the switch which shows the WWPN to which is
connected to, so if I can somehow get a report from the CEC listing the
PCHID and its WWPN, I can cross check what's cabled up and what's not.

Right now the way I do this is go into individual PCHIDS and do a problem
determination from the HMC.

Any help or pointers would be much appreciated.


I don't have solution , but I would look at HMC/SE capabilities.
From OS point of view you may not see all the PCHIDs.
Another source would be FC switch, but only for channels which are 
attached to given fabric.


Hints:
WWNN is constant for all ports
WWPN is consecutive for consecutive PCHIDs.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: PCHID WWPN report [EXTERNAL]

[Mainframe Sysprog]

Thanks Paul. It did list me the WWNN and WWPN but I believe those are for
the DASD subsystem that the paths connect to.

What I am looking for is a similar process to obtain the WWPN of the PCHIDS
on the processor end. This was still something new for me. Thanks for
sharing that.

On Wed, Mar 2, 2022 at 9:18 PM Feller, Paul <
02fc94e14c43-dmarc-requ...@listserv.ua.edu> wrote:

> You might consider trying ICKDSF with the ANALYZE option.  I used it to
> create a cross reference of PCHID to DASD port for the EMC DASD boxes we
> have.
>
> Sample of what I used.
> //ZOS1D3E  EXEC PGM=ICKDSF,REGION=128M
> //SYSPRINT DD SYSOUT=*
> //DSFDUMP  DD SYSOUT=*
> //SYSINDD *
>   ANALYZE UNIT(1D3E) NODRIVE NOSCAN HOSTACCESS(ALL)
> /*
>
>
> Paul Feller
> GTS Mainframe Technical Support
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Mainframe Sysprog
> Sent: Wednesday, March 2, 2022 9:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PCHID WWPN report [EXTERNAL]
>
> GM Listers,
>
> I want to obtain the WWPN of all PCHIDS on a processor and want to know
> what would be the fastest/easiest way to do that.
>
> The objective here is to do kind of an audit of what's connected to where
> for a new configuration and cross check it with intended HW configuration.
> I have the report from the switch which shows the WWPN to which is
> connected to, so if I can somehow get a report from the CEC listing the
> PCHID and its WWPN, I can cross check what's cabled up and what's not.
>
> Right now the way I do this is go into individual PCHIDS and do a problem
> determination from the HMC.
>
> Any help or pointers would be much appreciated.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Please note:  This message originated outside your organization. Please
> use caution when opening links or attachments.
>
> --
> 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: PCHID WWPN report [EXTERNAL]

[Feller, Paul]

You might consider trying ICKDSF with the ANALYZE option.  I used it to create 
a cross reference of PCHID to DASD port for the EMC DASD boxes we have.

Sample of what I used.
//ZOS1D3E  EXEC PGM=ICKDSF,REGION=128M  
//SYSPRINT DD SYSOUT=*  
//DSFDUMP  DD SYSOUT=*  
//SYSINDD * 
  ANALYZE UNIT(1D3E) NODRIVE NOSCAN HOSTACCESS(ALL) 
/*  


Paul Feller
GTS Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mainframe Sysprog
Sent: Wednesday, March 2, 2022 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PCHID WWPN report [EXTERNAL]

GM Listers,

I want to obtain the WWPN of all PCHIDS on a processor and want to know what 
would be the fastest/easiest way to do that.

The objective here is to do kind of an audit of what's connected to where for a 
new configuration and cross check it with intended HW configuration.
I have the report from the switch which shows the WWPN to which is connected 
to, so if I can somehow get a report from the CEC listing the PCHID and its 
WWPN, I can cross check what's cabled up and what's not.

Right now the way I do this is go into individual PCHIDS and do a problem 
determination from the HMC.

Any help or pointers would be much appreciated.

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

--
Please note:  This message originated outside your organization. Please use 
caution when opening links or attachments.

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

PCHID WWPN report

[Mainframe Sysprog]

GM Listers,

I want to obtain the WWPN of all PCHIDS on a processor and want to know
what would be the fastest/easiest way to do that.

The objective here is to do kind of an audit of what's connected to where
for a new configuration and cross check it with intended HW configuration.
I have the report from the switch which shows the WWPN to which is
connected to, so if I can somehow get a report from the CEC listing the
PCHID and its WWPN, I can cross check what's cabled up and what's not.

Right now the way I do this is go into individual PCHIDS and do a problem
determination from the HMC.

Any help or pointers would be much appreciated.

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

Re: S0C4 pic 4

[Joseph Reichman]

I would think the only way to prove is do a IVSK on the referenced storage 

I got it from subpool 0 so I assumed it was storage key 8

Regardless I wasn’t able to re-create it 

I did spend about 4 - 5 hours looking at it before I posted the problem 

The next day however Seymour asked me to post PSW and registers I wasn’t able 
to re-create it 

I really really didn’t rush to post as I said I did spend 4 - 5 hours looking 
it 

Thing is from a dump you can  tell the PSW key 

Storage key is a different matter only way is ISVK or if you are not authorized 
VSMLOC

The only thing I can say next time I encounter a problem 

I’ll sleep on it and next day first thing try it again 

Sorry 



> On Mar 2, 2022, at 7:56 AM, Peter Relson  wrote:
> As with too many posts like this, the best that can be said is "prove it". 
> Capture a dump and show what the dump formatter shows.
> 
> The PIC 4 occurred for one of the architected reasons.
> 
> Without sufficient data, it is not possible to help.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> 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: Meet Zorow, An Open Mainframe Project For z/OS Systems - Open Mainframe Project

[Seymour J Metz]

Has someone suggested Zaphrod Beeblebrox from HGTTG? Zeaot? Zing? Zoro?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Spiegel [dspiegel...@hotmail.com]
Sent: Tuesday, March 1, 2022 9:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Meet Zorow, An Open Mainframe Project For z/OS Systems - Open 
Mainframe Project

Take a cue from Charles Manson ... Zezozose Zadfrack

On 2022-03-01 20:01, PINION, RICHARD W. wrote:
> No wait, Zoltar, from a MST3000 episode.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Charles Mills
> Sent: Tuesday, March 1, 2022 7:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Meet Zorow, An Open Mainframe Project For z/OS Systems - Open 
> Mainframe Project
>
> [External Email. Exercise caution when clicking links or opening attachments.]
>
> Geez, they're going to run out of weird Z words.
>
> Zeme?
> Zelotic?
> Zarf?
> Zari?
> Zeze?
> Ziti?
> Zygon?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Mark Regan
> Sent: Tuesday, March 1, 2022 4:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Fwd: Meet Zorow, An Open Mainframe Project For z/OS Systems - Open 
> Mainframe Project
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.openmainframeproject.org%2Fblog%2F2022%2F02%2F23%2Fmeet-zorow-an-open-mainframe-project-for-z-os-systems__%3B!!HnnddUIWDII9UQ!GuvbfAnnC3hbYjun-Is7gluORxcAS5w0kiXFqvQmAWhJXlPRwysMd8ZeCiWQ%24data=04%7C01%7C%7C9a790e676a3f4ae7220408d9fbe8326e%7C84df9e7fe9f640afb435%7C1%7C0%7C637817797045843534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=2SGJiNkfmL4UOFMSN5B8Q%2FgSQ%2F0N0TV6Hx2tUAL%2B16w%3Dreserved=0
>
>
>
> ​Regards,
>
> Mark Regan, K8MTR General, EN80tg
> CTO1 USNR-Retired (1969-1991),
>
> RUENAAA/CNO WASHINGTON DC//OP-009QCP
>
> Nationwide Insurance, Retired, 1986-2017 z/OS Network Software Consultant (z 
> NetView, z/OS Communications Server) Contractor, Checks & Balances, Inc.
> Email: marktre...@gmail.com 
> LinkedIn:  
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmark-t-regan__%3B!!HnnddUIWDII9UQ!GuvbfAnnC3hbYjun-Is7gluORxcAS5w0kiXFqvQmAWhJXlPRwysMdwcaCbEB%24data=04%7C01%7C%7C9a790e676a3f4ae7220408d9fbe8326e%7C84df9e7fe9f640afb435%7C1%7C0%7C637817797045843534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=p5ncZgcjHSLNN%2BLUtPstwMVKr5MES%2FqR8rLfUPBGR0M%3Dreserved=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
> 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

--
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: ZAD and C/C++ (was:: 2.5 Heads Up)

[Seymour J Metz]

IMHO, Chien-Shiung Wu would have gotten the Nobel Prize had she been male.




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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Tuesday, March 1, 2022 10:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)

https://secure-web.cisco.com/1PXbV8bBOYAuiVtorpuZs7XE3pKinLwmLYKWPEJUV_PkTrzvWRyNuYDzK47foMg_IwN3TABRuvj8-6d952PU7Pg-fSwtIB4V3NLol2wqOLH_Vh_bIrhLnjTrXt1XW4HVTk9DPjC2uuSEoTeOojHiX-nvU6TI8d5otKWeqR9YnchPqlAF_87McO983XagIQA8zboCCtRKubYkttWZgaBVScNJ1y8ijfkw-96QjeEVIb-tXNTq_SrofW1RJZey9zfWvs4jPYQd59IlyRK6YdTzKvLbBlp0m3xC2UHlW5SDl1WqO-5gs_oQp6vKx5gRBemX90HZeonb5RR1Yvp9oMep7wsNFubNVVj7ErAUUu9IhfukBVrLwevduXMA2F4N1wwH-sZWGfpXU3rqfr-9M3MvnpGM_9fg4GFkuYyb5NRGWqV3O7CI-QrCTqoqu9HKiKviT/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FChin-Lung_Hu
 play for 2 MLB baseball teams.

On Tue, Mar 1, 2022 at 6:53 PM Charles Mills  wrote:
>
> > any ethnicity but their own
>
> In my much younger days -- the first significant system I ever worked on --
> I wrote a name-indexing scheme that assumed all surnames were at least three
> characters long. This was of course back in the day when we worried
> obsessively about bytes and CPU cycles.
>
> Turned out that the client -- Blue Cross of Northern California -- had
> hundreds of customers surnamed Ng.
>
> Oops.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Tuesday, March 1, 2022 10:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ZAD and C/C++ (was:: 2.5 Heads Up)
>
> Metz's Law of Anal Retentive Developers: "Never validate an input field
> unless you *KNOW* what the rules are: assumption, belief, habit, urban
> legends, etc., don't count!" The world is full of people that "validate"
> names without having a clue about any ethnicity but their own and e-mail
> addresses when the can't even spell RFC. "An e-mail address is invalid if it
> uses characters hat I don't use in mine." or some such idiocy.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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: S0C4 pic 4

[Peter Relson]

As with too many posts like this, the best that can be said is "prove it". 
Capture a dump and show what the dump formatter shows.

The PIC 4 occurred for one of the architected reasons.

Without sufficient data, it is not possible to help.

Peter Relson
z/OS Core Technology Design


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

Re: S0C4 pic 4

[Peter Relson]

As with too many posts like this, the best that can be said is "prove it", 
such as by taking a dump when the error occurred and showing what the dump 
formatter shows.

If a PIC 4 occurred, it was for one of the architected reasons.

Without sufficient evidence, it is impossible to help. 

Peter Relson
z/OS Core Technology Design


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