Hi Tom,
Not new/difficult, but, must be used appropriately or it can cause performance issues. When I worked at SIAC (NYSE) 2004-2010, one of the last mainframe activities I did was to look into why 6 Batch Jobs (run nightly) took over the machine to the point that TSO response time was painfully slow (after 1st period).  The original programmer decided to use UNSTRING to build CSV Data out of records from a KSDS. On a hunch, I rewrote the UNSTRING call in Assembler. The run times of these 6 (similar) Jobs went from 6 hours to just over a half hour.

Regards,
David

On 2024-03-15 16:55, Tom Harper wrote:
I used STRING / UNSTRING back in the early 1970s it’s not new nor difficult.

Unbelievable.

Tom Harper
Phoenix Software International

Sent from my iPhone

On Mar 15, 2024, at 4:20 PM, Farley, Peter 
<0000031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

+1 from me on continuing to learn the tools of our profession.  I use STRING 
and UNSTRING where they make sense, and I am still learning new things about 
their use every now and then.  Life-long learning is the only path to happiness 
and success.

I got the same ridiculous pushback from a senior manager one time on the use of 
“sophisticated” SORT verbs like JOIN because “. . . no one but you will know 
how to fix it when it breaks . . . let someone do it in COBOL instead . . .”.

Peter

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Bob 
Bridges
Sent: Friday, March 15, 2024 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Learning one's tools


To rant on a related subject, I once worked at a company that instituted code reviews; a 
new program would be gone over by a half-dozen coworkers to be sure it adhered to local 
standards.  This sort of thing is always painful to the coder, and nevertheless (I admit 
reluctantly) can have considerable value if done right.  One problem I had with it, 
though, is that the standards we created for ourselves admitted that there are times when 
exceptions should be made for special cases, and yet when those cases arose no exceptions 
were ever allowed; the team invariably flinched, leaned back in their seats and said 
"no, that's not according to our standards".



One particular example always rankled:  Whenever someone felt the need to use a 
STRING or UNSTRING command (I should have said we were COBOL developers), the 
team always struck it down on the grounds that STRING and UNSTRING are unusual 
commands and some COBOL coders would be unfamiliar with it.  My contention here 
is that that's absolutely true, and it's the job of the COBOL coder to ~learn~ 
the STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.



---



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communic

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
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

Reply via email to