Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Old file S/36 to AS400

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Old file S/36 to AS400

    You're right about the packed field's value being 43300. To retrieve the field values you are going to have to define a file with fields and then copy the data to that definition. Another method of accessing the data would be to create an input specification definition for the file and use that in all programs that read the file. Is there any source for the programs that read the file? If there is then that will provide the field lengths and attributes you can use to define a file. Without the layout you will have to guess at some of the field definitions from the view using the DSPPFM command. Trevor Lazarus

  • #2
    Old file S/36 to AS400

    On Thursday, July 10, 1997, 02:26 AM, Manuel Alvarez wrote: Hi, Denis Robitaille, this is my first time and I hope you understand my problem: There was a application in S/36 ... Your interpretation is right. If you want a quick and temporary solution: Create a PF with DDS that match the layout of your file (you will have to use the I spec of the RPG programs to find the file layout). Compile that PF then copy the content of your S36 file in it with the CPYF command specifying FMTOPT(*NOCHK) (this avoid level checking). You can then use that PF with any AS/400 program or utilities. A permanent solution would be to replace the S36 file with the newly created file. If you do so, make sure of the folowing: any program that update the file must update all numeric fields (blanks do not equal zero in externaly defined file). all BLDFILE statement must be replaced with a corresponding CRTPF statement (they are legal inside an OCL). If you have indexes (BLDINDEX) on the file, contact me again and i will go in more details. I hope this will help you

    Comment


    • #3
      Old file S/36 to AS400

      Hi, Bill Robins, this is my first time and I hope you understand my problem: Wow, how did I get so lucky??? Regardless, I even think I can help with this. Now, I must save this file (F00001, K00001, F00002) in a tape for passing his values to another AS400 (V3R1) who must work with these dates, and here is the problem I canīt see these "fields" (parts of F00002) who are packed decimal in the V3R1. I can only see symbols, these symbols donīt follow a logical serie. I tried with Query/400, but no solution. When I see in *hex format, with F10 and F11 in dspmbrpf, I can divine these "fields", so if I see: 0000430/000030F (the first seven are up and the other seven are down). I think itīs saying 43,300. But, I'm not sure. Can you help me? How can I work with this parts of the field F00002? How can I see them? I think what you are saying is that F00002 is a holding field containing logical data layouts within itself. The reason you are seeing the symbols is because the display station is trying to interpret the hexadecimal representation of each of the bytes in the packed decimal fields. I don't know of any way of creating a logical file format to convert a character field or portion of a field into a numeric one. (But if anyone else knows, they will speak up). One way might be to create a physical file description using DDS which specifies all of the "real" data fields in the record and then copying the old/original file into the new/defined one. The reason you can't see the packed decimal data in query is because it is also trying to represent the data as a character field. The AS/400 works on file/field definitions and it only knows this file as containing one or three fields. (If it came straight from the /36 the 400 probably thinks there is only one field). BR

      Comment


      • #4
        Old file S/36 to AS400

        On Thursday, July 10, 1997, 02:26 AM, Manuel Alvarez wrote: Hi, David Abramowitz, this is my first time and I hope you understand my problem: There was a application in S/36 some years ago in a S/36 system. This application saved the dates in a files with S/36 configuration (F00001, K00001, F00002). So, for example F00002 is a field with a lenght of 512, type *CHAR, but it had "fields": packed decimal, zone decimal and character type. I could see with dspmbrpf the character "fields" and the zone decimal "fields", but not the packed "fields". When I write "fields" there are not really fields, because there are only 3 fields (F00001, K00001, F00002), they are parts of a real field (F00002). Four or three years ago we bought an AS400 (V2R2), so this S/36 application was passed or migrated to work in AS400. But only the application, not the files. Now, I must save this file (F00001, K00001, F00002) in a tape for passing his values to another AS400 (V3R1) who must work with these dates, and here is the problem I canīt see these "fields" (parts of F00002) who are packed decimal in the V3R1. I can only see symbols, these symbols donīt follow a logical serie. I tried with Query/400, but no solution. When I see in *hex format, with F10 and F11 in dspmbrpf, I can divine these "fields", so if I see: 0000430/000030F (the first seven are up and the other seven are down). I think itīs saying 43,300. But, I'm not sure. Can you help me? How can I work with this parts of the field F00002? How can I see them? ================================================== ============================== ========== I'm sure there will be many more responses to your question other than mine. Here is my response: Define the actual fields of the file in a DDS, and create a new file using the CRTPF command. This file should have the same record length and key length as your original file, but the individual fields will have been defined. Copy the data from your original file, to your newly defined file using the CPYF command. Within this command use the MBROPT(*ADD) parameter, and the FORMAT(*NOCHK) parameter. Once this has been done, you should be able to use QUERY to view the data easily, and with all fields being displayed. David Abramowitz

        Comment

        Working...
        X