TYPE declaration and usage

[billhsln]

I have defined a record format as:

Code Select Expand

TYPE OPQ11REC
DEF RECORD11[2]:ISTRING
DEF BATCH_NUMBER[5]:ISTRING 
DEF SOURCE_OF_BATCH[1]:ISTRING 
DEF OPERATOR_ID[3]:ISTRING 
DEF ENTERED_ORDERS[3]:ISTRING 
DEF SIGN_FOR_DOLLARS[1]:ISTRING
DEF ENTERED_DOLLARS[9]:ISTRING
DEF DEPOSIT_DATE[10]:ISTRING
DEF COUNTRY_OF_ORIGIN[3]:ISTRING
DEF FILLER11[363]:ISTRING
DEF crlf11[2]:ISTRING
ENDTYPE

DEF OPQ11:OPQ11REC

I need to write this info out into a BFILE, this has a record length of 402 bytes.  When I load OPQ11.RECORD11 with "11", all I see is 1 followed with a binary 00, I want it to have 11 and all the rest of the record (except for CRLF11) to have either values I assign or blanks.  What I end up with is one character removed from what I set the field as and binary 00 every where else.  I am trying to write a fixed format record, like I did back in the old QBASIC days, but this does not work in IWB.  Is there a way to force the entire record to be blanks and make it so that when I define a field as [3]:ISTRING and assign it "xxy", I end up with xxy in the field, not xx and binary 00. I have 4 more record types all defined like the above, all defined as 402 chars.

Thanks,
Bill

[LarryMc]

Strings in IWB have always been NULL terminated
So why does it have to be 402 characters? Why can't you add 1 to each element to account for the nulls?
why does it have to be spaces as opposed to nulls?

[billhsln]

Writing data to AS/400 flat file, which is fixed format. I need my first field in the 4 different formatted records to have either 11, 21, 31, or 41.  Operator_ID is persons initials (3 chars).  I was able to do this back in  the old DOS Basic.

The file I am trying to match to is a Cobol formatted file on the AS/400.

Bill

[LarryMc]

Writing data to AS/400 flat file, which is fixed format....

Do you also need to read that same flat file or just right it?

[billhsln]

Will need to be read in by Cobol program and then I reformat it and store it in a DB2 tables.

Bill

[LarryMc]

So, your IWB program needs to be able to read the file AND write the file in the same format?

[billhsln]

Original file I am reading is TAB delimited.  I convert it to a Fixed Format and then load that file to AS/400 and run Cobol program to take that data and load it into a DB2 table.

Bill

[LarryMc]

Original file I am reading is TAB delimited.  I convert it to a Fixed Format and then load that file to AS/400 and run Cobol program to take that data and load it into a DB2 table.

Bill

ok, so you only need the IWB program to write the flat file.

Now, are you using the structure as part of converting from the tab format or was that just something you come up with trying to write the flat file.

I just need to know whether or not I need to use the structure in the example I'm going to build.

[billhsln]

Here is the Cobol description I used to create it:

Code Select Expand

*    LRECL = 400
       01  OPQ0005-BATCH-REC-11.
           05  OPQ0-11-RECORD-TYPE         PIC X(02).
           05  OPQ0-11-BATCH-NUMBER        PIC 9(5).
           05  OPQ0-11-SOURCE-OF-BATCH     PIC X(1).
           05  OPQ0-11-OPERATOR-ID         PIC X(3).
           05  OPQ0-11-ENTERED-ORDERS      PIC 9(3).
           05  OPQ0-11-SIGN-FOR-DOLLARS    PIC X(1).
           05  OPQ0-11-ENTERED-DOLLARS     PIC 9(7)V99.
           05  OPQ0-11-DEPOSIT-DATE        PIC X(10).
           05  OPQ0-11-COUNTRY-OF-ORIGIN   PIC X(3).
           05  FILLER                      PIC X(363).

This is just for the '11' record, I have 3 more record formats for different record types that I have to match to.

Bill

[LarryMc]

I'm having trouble asking the right questions tonight.

1. Have you written the code to read the TAB delimited file, Y/N?
2. If Y, are you putting the field info in the OPQ11REC structure elements, y/n?
3. If N, then have you defined the variables you are putting the info in,y/n?

[billhsln]

Sending CSV file I start with, Cobol description of all 4 different formats and my IWB source code to you directly via E-Mail.

Hope that will give you all the info you need.

Thanks,
Bill

[LarryMc]

Sending CSV file I start with, Cobol description of all 4 different formats and my IWB source code to you directly via E-Mail.

Hope that will give you all the info you need.

Thanks,
Bill

Got it. Give me some time to study it and I'll give you a solution.  It will probably be tomorrow.

[billhsln]

Other solution that I can think of is create single variable DEF ostr[402]:ISTRING and set it to blanks first then load directly into correct positions only data that is Not blank.  Created spread sheet with starting position and length.  Will send it along also.  Just created it a few minutes ago.

Thanks for taking a look,
Bill

[LarryMc]

ISTRINGS end with a null
you'll wind up short the last character

[Rock Ridge Farm (Larry)]

I thought I was the last dinosaur supporting AS400 systems - at least the older ones.

Larry

[billhsln]

Sorry to disappoint.  I write in RPG and COBOL on an AS/400 down in Corsicana Texas for Collin Street Bakery.  I use IWB to write utilities and conversions for them, so I actually use IWB for production work.  Use it for fun stuff too.

Just a thought, I know that for a STRING variable, we need the x'00' to know where the end is.  It is also used in the ISTRING, but if we define the ISTRING as [5] and store 'ABCDE' in it, why could it not assume that we want 5 chars and not need the x'00'?

I do lots of fixed format stuff and none of it needs x'00', but I would prefer it to blank fill instead.  Maybe this could be a switch or command (NONULLS) for ISTRINGS?  So, if you set NONULLS on, ISTRINGS will be blank filled, only for ISTRING, not STRING.  That is why I have the FILLERs to make sure that the file is 400 chars for each of the 4 different record formats I am writing.  I am writing 402 for the CrLf to be added to the end.

Thanks,
Bill

[LarryMc]

Maybe this could be a switch or command (NONULLS) for ISTRINGS?  So, if you set NONULLS on, ISTRINGS will be blank filled, only for ISTRING, not STRING.

Doing that would require that everything associated with ISTRINGS and STRINGS in the compiler be completely rewritten.
Passing a string as a parameter to a subroutine would then require us to distinguish between the different types of strings.

Internally, the length of an ISTRING would have to be stored because any pointer function(which reads a memory location) wouldn't know how much memory to read.

BTW, did the code I modified work for you?

[billhsln]

It has been completed, switched from CHAR to ISTRING and it looks like what I want it to look like.  Will need to pass the data thru the system and make sure it worked ok.

Thanks again,
Bill

[LarryMc]

It has been completed, switched from CHAR to ISTRING and it looks like what I want it to look like.  Will need to pass the data thru the system and make sure it worked ok.

Thanks again,
Bill

Glad you got it working!
Sorry I couldn't have been of more help.

[billhsln]

You did help quite a bit.  It is working, so I consider it a good thing.

Thanks again,
Bill