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


  • Subject: RE: Copying file with *nochk
  • From: "Kahn, David [JNJFR]" <DKahn1@xxxxxxxxxxxxx>
  • Date: Thu, 23 Sep 1999 12:07:06 +0200

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

Follow-Ups:

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.