-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Don Russell Sent: Wednesday, January 28, 2009 1:10 PM To: [email protected] Subject: Re: /*XEQ /*XMIT question
<snip> You mean on the second job card? Good question. :-) That's why I liked /*XMIT etc... it seems to replicate the original JOB card, so if there's problems with that, the original job stream is rejected in whatever manner is "normal". Of course that means passwords etc must be synchronized across the different MVS systems, but that becomes a user problem. :-) <snip> That is the start of the problem. And you are on the edge of the problem that I have run into. If auditors state that you cannot have passwords in the open (which your JOB card will have to have) and you management agrees, then your submitting system can't have the UID/Passwords in the JOB Statement. So if the submitting system does not have the UID and Password of the submitter matching the "profile" on the target system... This is where the JOB syntax error problem comes in. If you have a JOB syntax error it depends on what it is as to which system will detect it and how will it get reported. In my case, the submitting system doesn't detect the problem (finger-checked keyword for USER), the receiving system does detect it, and fails the JOB. BUT, because it is failing because it doesn't have a matching profile (since the "USERID" keyword ...), the JOB disappears. AFAIK, ALL MVS systems are using the same JOB keywords today. I believe this has been true since the last of the base 370 systems was "obsoleted" by the removal of 370 base system support (MVS free thru SP1). Regards, Steve Thompson -- Opinions by this poster may not be those of poster's employer. -- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
