🚀 go-pugleaf

Pardon my ignorance, but are the jobs submitted from TSO/ISPF?  Could you create a REXX substitution for SUBMIT?  REXX has no problem acquiring that information.  The following is the JESJCL output of my SUBMIT "overload".  Note "JOB SUBMITTED FROM".  If so inclined, you could modify the REXX submit to "log" the submissions.

SDSF OUTPUT DISPLAY GSDUP35  JOB00728  DSID     3 LINE 0       COLUMNS 02- 161
COMMAND INPUT ===>                                            SCROLL ===> CSR
******************************** TOP OF DATA ************************************
       1 //GSDUP35  JOB (CMS000,000009),'GSDUP35',CLASS=A,MSGCLASS=V,
         //             USER=DONN,NOTIFY=DONN
         //* JOB SUBMITTED FROM CMS000.#000010.JCL(GSDUP35)
         //*


I'm probably way off base, but thought I'd put my two cents in.

dvn


-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]On Behalf Of Gary Weinhold
Sent: Tuesday, October 25, 2005 8:38 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: How to find PDS member name details


To expand on John McKown's response below, if the technical support area
(or whatever it is called) offers standardized procedures in a common
proclib with sample JCL for all known requirements for overrides by
users, and offers to revise those common procs if they are not flexible
enough for users, then it is questionable how much support they should
give to user's private versions of those procs.  If new or revised
functions are added to the existing procs and broacast to all users,
then those with private procs/JCL should be taking responsibility for
reviewing and implementing those functions for themselves.

However, I will admit that Mr. Baker's company's approach ensures more
work (and possibly employment) for technical support staff.  I wish you
success with trying to turn that environment around.

Gary Weinhold,
Data Kinetics, Ltd.

"McKown, John" wrote:
>
> > -----Original Message-----
> > From: IBM Mainframe Assembler List
> > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mike Baker
> > Sent: Tuesday, October 25, 2005 1:25 AM
> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> > Subject: Re: How to find PDS member name details
> >
> >
> > The problem is an extremely messy environment. Years ago some
> > standard IMS
> > database procedures were created, and people were meant to execute the
> > centrally stored procs, and use whatever JCL overrides they
> > needed. Now...
> > 18 years later, everyone their own personal version/s of the
> > procs, and
> > they execute these most (not all) of the time. The test
> > environment is a
> > complete mess, and no-one has a clue what's going on.
> >
> > IMS version 7.1 does not force the use of the DBRC=Y
> > parameter in the JCL,
> > and whilst you can code it in the centrally stored procs,
> > that is no help
> > if people don't use those procs. Nor do they want anyone
> > telling them what
> > they should be using...  even though their own source
> > libraries are now in
> > a state of complete chaos.
> >
> > So... the intention would be to write a front-end for the IMS region
> > controller program, rename the IBM one, and XCTL to it after
> > extracting
> > various items of info. such as the PDS member name details.
> > And with the
> > gathering of this information, then control can be established.
> >
>
> Well, this is just my personal opinion. But it is what I did once in a
> similar (but not as bad) situation. It does require management
> enforcement. Basically, I say: "Do it this way! If you don't, and you
> have a problem, then YOU have a problem. If you bother me, I will laugh
> at you and tell you to go away." Rude, crude, and socially unacceptable.
> But sometimes that's the only way to clean up a really messy situation.
>
> --
> John McKown
> Senior Systems Programmer
> UICI Insurance Center
> Information Technology
>
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and its'
> content is protected by law.  If you are not the intended recipient, you
> should delete this message and are hereby notified that any disclosure,
> copying, or distribution of this transmission, or taking any action
> based on it, is strictly prohibited.