|
Joep, You're absolutely right on all points. It illustrates the folly of trying to program describe a DS when an external description is available. I also thought that this would be a prime candidate for a cycle program. I'd avoided saying that before because it upsets some people. :-) For the record a fully working program using program described files to replace Çagatay's 40-odd lines is shown below. This should have the same effect as a straight CPYF. FSSK4AYP IP F 115 DISK FSSK4AYTXO F 115 DISK * ISSK4AYP NS 01 I 1 115 REC * OSSK4AYTXD 01 O REC 115 However... As Çagatay eventually wants to have the file on a PC, it might be that he does need to unpack the fields. In this case CPYF would be no good to him anyway. He could use the following DDS to define the output file, resulting in a 145 byte record as in his program described DS (ignoring the comments). R SSK4AYT YIL 4S 0 DONEM 1S 0 SUBE 2S 0 SKOD 1S 0 ISKOLK 4S 0 ISYNO 9S 0 ILKOD 2S 0 ILCKOD 2S 0 TASNUM 2S 0 ISKODU 1S 0 BORTUR 1 SAYFA 4S 0 SIRA 2S 0 SSICIL 13 AD 18 SAD 18 BORGUN 3S 0 KAZANC 10S 0 K18 1 IGT 4S 0 ICT 4S 0 SAYGUN 6S 0 K18 1 IGT 4S 0 ICT 4S 0 SAYGUN 6S 0 SAYKAZ 12S 0 GNGUNT 7S 0 GNKAZT 14S 0 He would then need a program to read one and write the other. Our cycle program now has externally described files. It needs a C spec but can dispense with the O specs. FSSK4AYP IP E DISK FSSK4AYTXO E DISK * ISSK4AYR I BORTURU BORTUR I GNGUNTOP GNGUNT I GNKAZTOP GNKAZT * C WRITESSK4AYT But of course structured programming is superior so we shouldn't do it this way. ;-) Dave Kahn Johnson & Johnson International (Ethicon) France Phone : +33 1 55 00 3180 Email : dkahn1@jnjfr.jnj.com (work) dkahn@cix.co.uk (home) -----Message d'origine----- De: Joep Beckeringh [mailto:joepb@tip.nl] Date: 23 September 1999 01:46 À: RPG400-L@midrange.com Objet: Re: Copying file with *nochk Çagatay, Apart from the bug noticed by Dave Kahn, causing an extra record in the output file, there's two other things I noticed: 1. In the DDS you don't specify whether the numeric fields should be zoned or packed, so they default to packed. Yet, in the data structure that is apparently meant for the output file, the numeric fields are defined as zoned. That means a CPYF FMTOPT(*NOCHK) would never work (the output record would have some garbage where the packed numbers where in the input file). 2. The redefinition of your data as field DATA is commented out in the RPG. This program would only write blank records to the output file. (Dave: No need for DOW/DOU wars here; typical case of primary file; no C-specs needed at all). +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-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.