IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Gets the length of the data read by the READ


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Thu May 08, 2014 10:49 pm
Reply with quote

The input is a USS file that was filled by a 'curl' command. The file size can be anything from 0 to (roughly) 32kb. It contains a well formed XML document in ascii that will be passed back to another program.

I am reading the file using a COBOL READ, into a PIC X(32000) field. I do a second read to make sure I'm at end of file.

I used a loop to scan down from the end for the first '>' in ascii. That is working, but it seems a little old fashioned.

Is there a special register or anything that gets set for the length of the data read in by the READ statement?
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu May 08, 2014 11:08 pm
Reply with quote

No.

Looks like you can't use the VARYING ... DEPENDING ON ....

Looks like you can rely on the record area being padded with trailing space if a record (up to delimiter, delimiter is discarded) does not fill the entire record area.

So, count the trailing blanks. Subtract from the length of the record-area (LENGTH OF or FUNCTION LENGTH) and you have the number of bytes of data.

Looks like it gets cute if you have a long record. The first part will be presented as a record, and remainder of the record data will be presented to you has the subsequent record.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Fri May 09, 2014 12:06 am
Reply with quote

Thanks Bill,

I ended up using this:
Code:

05 WSH-REPLY-LENGTH-GT        PIC X(01) VALUE '>'.


OPEN INPUT USS-REPLY-FILE                           
READ USS-REPLY-FILE                                 
DISPLAY 'READ STATUS: ' WSH-USS-REPLY-FILE-STAT     
READ USS-REPLY-FILE                                 
IF WSH-USS-REPLY-FILE-STAT = '10'                   
    PERFORM                                         
        VARYING WSH-REPLY-LENGTH FROM 32000 BY -1   
          UNTIL USS-REPLY-REC(WSH-REPLY-LENGTH:1) =
                WSH-REPLY-LENGTH-GT                 
    END-PERFORM                                     
    DISPLAY 'REPLY LENGTH: ' WSH-REPLY-LENGTH       
    DISPLAY USS-REPLY-REC(1: WSH-REPLY-LENGTH)     
    CALL 'EZACIC05' USING                           
                    USS-REPLY-REC                   
                    WSH-REPLY-LENGTH               
    DISPLAY USS-REPLY-REC(1: WSH-REPLY-LENGTH)     


The WSH-REPLY-LENGTH end up with the exactly data length in it. I may skip a step and just look for 'not = space', that would save me having to make the '>' ascii.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Fri May 09, 2014 12:08 am
Reply with quote

Yep, that worked...

Code:

PERFORM                                               
    VARYING WSH-REPLY-LENGTH FROM 32000 BY -1         
      UNTIL USS-REPLY-REC(WSH-REPLY-LENGTH:1) NOT = ' '
END-PERFORM                                           


Right now, I'm just going to make it work for a single 32kb record. If this get approved for prod, I'll figure out the concatenation of multiple records.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri May 09, 2014 12:27 am
Reply with quote

Interesting that you use the data-record only after the end-of-file. I've never done that with QSAM, perhaps it works, but I'd not want to rely on it :-)

I know it's just a POC...

I think the easiest way to deal with large records which may break you input area is to just no allow it to happen. There is a small QSAM limit for record sizes, but it may be that LINE SEQUENTIAL allows you to define bigger records. If so, you could go for bigger than expected maximum, and test that part of the record for space in one lump (will be faster than the loop).

If you don't do something like that, I'm not sure you can reliably tell when a record has been split.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Fri May 09, 2014 12:54 am
Reply with quote

Good point about the record area....I'll move that out of there before I touch it. It's probably only a matter of time before I'd get a S0C4.

The way I read the book is that if there is ANY data left in the stream, you get a good read status. If you had space for more data than you read, you also get a good status. If you did NOT have enough space, then you still get good return code.

So...you have to read until eof no matter what, just to make sure.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri May 09, 2014 1:04 am
Reply with quote

Well, I read that the same way. The thing is, how do you stick the data together again?

Fine if record ends with

Code:
..somestuff<sometag


And the next begins

Code:
><then another tag>....


But

Code:
..somestuff<sometag>
<then another tag>....


Is more tricky. How do you know that it is continuation, rather than a separate record? It's XML. You shouldn't rely on the order, even if you can specifically. OK, you know the order, it's come from a computer. It'll be reliable. No-one'll ever change the first XML element...
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri May 09, 2014 3:43 am
Reply with quote

From what I see in the Language Reference manual, for the syntax diagram,
Code:
RECORD VARYING FROM 0 TO 32767 DEPENDING ON WS-LENGTH
appears to be valid for line sequential files. If so, WS-LENGTH would contain the number of characters read for each READ statement.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri May 09, 2014 4:49 am
Reply with quote

Yes, sorry Ed, I was mis-reading another part of the manual. That'll be the man. No messing.

I assume since it is only for HFS files, it will understand the ASCII line-feed. I'm think there is a chunk on it in the Programming Guide.

Assuming that works, and assuming that you can define a bigger record for a line-sequential file, I'd go for a really big record so you can never get the split.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Fri May 09, 2014 7:20 pm
Reply with quote

Robert's method worked perfectly:

Code:


SELECT USS-REPLY-FILE ASSIGN TO USSREPL     
    ORGANIZATION IS LINE SEQUENTIAL         
    FILE STATUS IS WSH-USS-REPLY-FILE-STAT. 

FD  USS-REPLY-FILE                       
    RECORDING MODE IS V                 
    RECORD VARYING FROM 1 TO 32000       
           DEPENDING ON WSH-REPLY-LENGTH.
01  USS-REPLY-REC        PIC X(32000).   

01 WS-FIELDS.
    05 WSH-REPLY-LENGTH           PIC 9(09) COMP.

OPEN INPUT USS-REPLY-FILE                     
READ USS-REPLY-FILE                           
READ USS-REPLY-FILE                           
IF WSH-USS-REPLY-FILE-STAT = '10'             
    DISPLAY 'REPLY LENGTH: ' WSH-REPLY-LENGTH 
    DISPLAY USS-REPLY-REC(1: WSH-REPLY-LENGTH)
END-IF.                                       
CLOSE USS-REPLY-FILE.                         


FYI, I did hit a problem with using the record area after the fact, so I changed that in the current version.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri May 09, 2014 7:42 pm
Reply with quote

Glad to hear that, Ed. I haven't used line sequential files on a mainframe (yet), but I have used them extensively on a PC under Cygwin.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts How to split large record length file... DFSORT/ICETOOL 10
No new posts PARSE Syntax for not fix length word ... JCL & VSAM 7
No new posts Error to read log with rexx CLIST & REXX 11
No new posts Data set Rec-Cnt and Byte-Cnt Testing & Performance 2
No new posts VB to VB copy - Full length reached SYNCSORT 8
Search our Forums:

Back to Top