|
You can split the 800 in half to get the display VS update programs. We have a display & update program that is supported by one map. So we have 400 display, 400 updates and 400 maps. We are getting Progen and will use it to replace a language called General (SGT). The problem that we are looking at with all the code is that our online system has 27 years of business rule edits and functions. If we had to get into trying to decide what each of those edits are really about, we would never be able to convert. We need a way to keep in place the basis of the cobol edits and just change the CICS transactions to the equivalent native transactions. We will take a better look at Progen to help us out. I am excited about Progen, so maybe we can get even more use out of it than what we had originally intended. Thanks! Dusty "Stone, Joel" <StoneJ@GourmetAward.com> on 12/31/2001 11:12:38 AM Please respond to cobol400-l@midrange.com To: "'cobol400-l@midrange.com'" <cobol400-l@midrange.com> cc: (bcc: Dusty Hansen/UT/FBFS) Subject: mainframe cobol to AS/400 cobol This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. -- [ Picked text/plain from multipart/alternative ] We converted from a cobol mainframe environment (not IBM) to the AS/400 several years ago. Of the 800 interactive pgms, how many are simple maintenance or display programs (Read a customer record, display on screen, allow add/change/delete)? We used a code generator to quickly develop these types of pgms. We purchased Progen, which generates RPG code (we rarely had to look at the RPG code, although it helped us to learn RPG). Only a handful of pgms required complete re-writes. Most were replaced with Progen or migrated easily. -----Original Message----- From: dkhansen@fbwc.com [mailto:dkhansen@fbwc.com] Sent: Friday, December 21, 2001 2:28 PM To: cobol400-l@midrange.com Subject: (no subject) My name is Dusty Hansen. I am a programming manager of 17 programmers. We are going to try and go from our current COBOL CICS main frame platform to COBOL/400 on the 400. We are currently running our batch processing on the 400 but we need to migrate all of our 800 COBOL programs and 400 BMS maps to the 400. We will then have our interactive portion on the 400 and we can get ride of the bigger main frame. I have read some very good mail posted in the archives. This has been very valuable. I am looking to see if we there is a way that a called program can kill the calling program and run on it's own? If you have a stack and the main calling program calls a sub program which calls others, do we have to keep the relationship of the main program or can we kill it at some point? With what we are doing we do not need the initial calling program once we have transferred control to one of the sub programs. In our CICS world we have a display program that reads a record and then sends a map to the screen. The display program then goes away. If there has been any thing coded on the screen the update program is invoked and reads the map, updates the record and then send out the output map (screen). the update program then goes away. This is handled by using the CICS XCTL command. This will transfer control to another program and then go away. Is there an equivalent situation for COBOL/400? _______________________________________________ This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list To post a message email: COBOL400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l or email: COBOL400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/cobol400-l. _______________________________________________ This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list To post a message email: COBOL400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l or email: COBOL400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/cobol400-l.
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.
midrange.com
