|
Tim, I have customers that have the same restrictions. What the programmers end up doing is creating a complete duplicate of the production environment and have the user guide them through getting to the same point in the program. Problems of course are massive disk usage for the duplicate environment, security in the test environment, and system overhead, not to mention much poorer productivity. You can bring these issues to management and beg for at least temporary authority to prove the productivity gains, but it may not help. On the upside I sold one of these customers 128GB of disk and have three contractors employed there! Some might ask why not have a test data set that is much smaller but effective. True, this is a good idea but they are rolling out so many new products that the test data set never has any of the new types of data in it and that is usually where the problems are. We have tried to convince them to write a program (or use DataMirror Transformation Server) to keep a test set up to date to no avail. (Remember the oil filter man; 'You can Pay me now, or Pay me Later') Larry Bolhuis Arbor Solutions, Inc lbolhui@ibm.net Tim Truax wrote: > > Hi folks; > I got a question concerning my current programming job. Here's the > scenario: I am assigned a program that requires fixing, and this > program is maybe 4 CLP's and 5 RPG programs deep into CALL's, therefore > knowing exactly (dspjob info) the files it is accessing and any > variables in a program *ENTRY PLIST is very helpful and a valuable time > saver as well as an error preventer. Normally what I would do is this: > a) Have production user sign on to the system. > b) Identify the name the AS400 has assigned to this users job. > c) Then I would do the STRSRVJOB command on this job. > d) Then a STRDBG on the specific program I wanted processing to stop on, > for my brief (information) collection. > e) I would then allow the user to progress to the program area I wanted > to look into. > e) At program stop time I would view the PARMS in the *ENTRY PLIST of > the program and the actual files the program was pointed at. > Well guess what! Programmers at this company are not AUTHORIZED to do > this on a production machine, this has me floored! > > I would appreciate any suggestions my fellow-list-people would offer me > to somehow circumvent this perplexing problem. > Thanks very much in advance. > > ---- > Tim & Dana Truax... and Caleb 4 years old. > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.