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