Why not have job 2 execute a program to determine if it is running in test or production and email the development team or the entire list respectively? Converting invalid email addresses to valid email addresses seems to add additonal complexity for no apparent reason.

Or, you could add a program to job 1 to check if it is running in production or test and take appropriate action.

That would depend upon your particular site and its security package. Only someone working at your site could advise you about it; however, if the test region (LPAR?) security data base is ever refreshed from production (or somewhere else) you could lose the protection.

Issue: During testing in dev/QA, Job 2 would actually send out emails to all the users present in the file. This also happens if somebody accidentally runs Job 2 in dev/QA.

Your question is somewhat site-specific as Robert has also said. On the other hand, how come a file, which is presumably should have a PROD High Level Qualifier (HLQ) for files, is available in test LPAR also? Should not the HLQ of PROD and TEST be different at first place?

As one of the solutions, you can also use symbolic data-set name for the file having e-mail contact details. One of its nodes should be replaced with 'something' which distinguish Test and prod LPARs at your shop that way, a Prod file, will not be referred in Test/QA (which is strange and site-specific, to start with).

I would caution that invalid email addresses can cause trouble. I put an invalid address on purpose for exactly the same reason, and I managed to hose up the bridge between mainframe and the SMTP server.

The worst part was that it happened at like 6:30 one night, and I KNEW it had happened. I started calling people to let them know I had broken it, but nobody knew who the owners were.

I kept calling the next morning and still had no luck finding the right people. However, there were about fifty open tickets for missing email from production jobs.

Of course, three days later, I get a screaming phone call from the owner trying to get me fired for doing this. Luckily I had written docs from the moment of failure that I had been trying to reach him.

Currently, I have requested system people to restrict the access to NONE for that perticular dataset for the development users till further notice. Now as long as testing goes on none of us can send emails to production people

Currently, I have requested system people to restrict the access to NONE for that perticular dataset for the development users till further notice. Now as long as testing goes on none of us can send emails to production people

What if someone requests to execute the Job using scheduler, e.g. CA7? Okay, that's again site-specifc but that possiblity might exist.

Fine. However, I don't see that as a good foolproof method. Also, at all the sites I've been to, there was never a way to refer a file from Prod in Test LPAR as-it-is, unless of-course you XMIT the file. Are the Jobs in question using ROUTE XEQ?

With all those site-specifc stuff, suggestion form Bill looks best that you just have a different file for different environments

With all those site-specifc stuff, suggestion form Bill looks best that you just have a different file for different environments

We do have this in place for dev-T*, QA-#*,prod-P* as first qualifier but in every across the regions these files are accessible. This is purely site specific tho.

Also this is needed in case if I have to generate some reports in dev based on the production data then I either I should be having a access to prod(P*) files in dev region or copy data from P* to T* and use T* file in dev to generate the reports.So better make P* available in every region directly.

Jeez, I don't want to know about your accessing Production data outside of a Production environment. Fix it, quick, as the consequences for the company/companies involved can be rapid and severe.

Have a dataset for Text. Have a dataset for E-mail addresses. Have a process which puts the two together.

Then you can use "whatever" combination of inputs for these as suit your requirement at the time. You can have multiple "dev" datasets, multiple "prod" datasets, you can use the prod datasets from test if/when necessary.

I am sure your suggestions would certainly be bullet proof for the issue I have mentioned, but this is an existing process in place and just for testing purpose this change they would never be accepting proc/jcl.

But moreover I am just trying to understand how would

Quote:

Have a dataset for Text. Have a dataset for E-mail addresses. Have a process which puts the two together.