× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



In the mid 90s, I had a job working for a contractor with work at a
Federal agency. One task I was assigned was to prepare standardized
documentation of program logic used in COBOL programs that ran on S/36
machines.

One program had this:

READ somefile
PERFORM UNTIL EOF
blah
blahI saw the second READ
READ somefile
blah
blah

Above not correct COBOL-74 syntax.

Point was that second READ should have been last in the performed
paragraph. I got into trouble when I pointed that out. Then, I was
told they knew about the issue, but would not fix it due to the
difficulty of getting changes through Quality Acceptance. Program had
failed during a production run - but error was extremely obvious just
looking at the source.

One last comment: for some programs, this was a second go-round on
program documentation. I wish that was funny.

John McKee

On Sun, Nov 4, 2012 at 3:45 PM, aec <cfuture@xxxxxxxxxxx> wrote:

On 11/2/12 4:33 PM, Briggs, Trevor (TBriggs2) wrote:
We get to use new skills on new development and major revisions, but
I've never worked anywhere where we had time to re-write programs just
because we wanted to!

Do you work for the government?
---
Nah, they don't re-write programs just because they don't feel like it!

FAA is still using 1970s technology in a lot of places, but they do a
bit of a better job for highly visible applications like space! Or else!



Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of John Allen
Sent: Friday, November 02, 2012 4:29 PM
To: 'RPG programming on the IBM i / System i'
Subject: RE: Should I replace all CHAIN, SETLL, and READs to SQL

Lol,

See you may be one of those programmers that goes wondering
off because your company is not keeping your skills up to
date.

We don't have much turnover here :)


John


-----Original Message-----
From: Briggs, Trevor (TBriggs2)
[mailto:TBriggs2@xxxxxxxxxxx]
Sent: Friday, November 02, 2012 4:19 PM
To: RPG programming on the IBM i / System i
Subject: RE: Should I replace all CHAIN, SETLL, and READs to
SQL

Do you have any vacancies?

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of John
Allen
Sent: Friday, November 02, 2012 4:09 PM
To: 'RPG programming on the IBM i / System i'
Subject: RE: Should I replace all CHAIN, SETLL, and READs to
SQL

Richard,

We are always updating our existing code to ensure that it
is up to date and using the latest technology.
We don't want to have programs that were written 15 years
ago if there is more advanced way of doing something.

Most programmers never get the opportunity to update their
existing programs for just the reason you state ("just for
the sake of the latest and greatest DB access
technique")
Our programmers do get this opportunity on a regular basis.

Just because a program is "good working code" doesn't mean
that it can't be improved.
Sometimes we just change good working Fixed format programs
to Free format for the heck of it programmers learn new
skills, programs are easier to maintain and we end up with
better good working code

And our programmers like the fact they get to keep their
skills up to date and they don't go wondering off to another
company :)



Thanks

John




-----Original Message-----
From: Richard Schoen [mailto:richard@xxxxxxxxxxxxxxx]
Sent: Friday, November 02, 2012 2:02 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Should I replace all CHAIN, SETLL, and READs to
SQL

Why would you consider re-engineering good working code just
for the sake of the latest and greatest DB access technique.


My answer is absolutely leave your RLA in place. That's one
of the benefits of using RPG.

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and
Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT

------------------------------

message: 2
date: Fri, 2 Nov 2012 11:06:03 -0400
from: "John Allen" <jallen@xxxxxxxxxxx>
subject: Should I replace all CHAIN, SETLL, and READs to SQL



I have been thinking about changing all CHAINs SETLLs and
READs in our software to SQL



Our programs use these operations for various reasons such
as:

Simple SETLL to check if a value is valid

Reading records for loading subfiles

Chaining by RRN (used in subfile processing, the input file
does not have a unique key so RRN is stored in Subfile then
used for accessing the original record)

Reading and chaining to several files for processing
thousands of records and doing validations, calculations
etc.



My main concern would be:

How this would affect performance

Does SQL allow for accessing records by RRN.



Does anyone have any thoughts on why this is a good or bad
idea



Thanks



John



--
This is the RPG programming on the IBM i / System i
(RPG400-L) mailing list To post a message email:
RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i
(RPG400-L) mailing list To post a message email:
RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

************************************************************
************************************************************
************************************************************
************************
This message originates from Lincare Holdings Inc. It
contains information which may be confidential or privileged
and is intended only for the individual or entity named
above.
It is prohibited for anyone else to disclose, copy,
distribute or use the contents of this message.
All personal messages express views solely of the sender,
which are not to be attributed to Lincare Holdings Inc., and
may not be copied or distributed without this disclaimer.
If you received this message in error, please notify us
immediately at MailAdmin@xxxxxxxxxxx or (800) 284-2006.
************************************************************
************************************************************
************************************************************
************************

--
This is the RPG programming on the IBM i / System i
(RPG400-L) mailing list To post a message email:
RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.