|
View previous topic :: View next topic
|
| Author |
Message |
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
Hi,
Enterprise COBOL allows to read the files in reverse order only if they are single-reel and are FB. I'm not sure what happens under the covers when file is read in reverse order.
If I experiment with VB records it would give error, per manuals(I've not tried it yet.). Manuals also say, after the opening of a tape-file the file is positioned at it's beginning. However, if REVERSED is used with OPEN statement, it positions the file at its end. OK fine - but the questions which aries from this:
1. What's wrong with VB Files? Why can't VB files be read in reverse order, of course assuming all other characteristics required are already qualified?
2. Why this is not applicable to files on DASD? Can't actuators move anywehre? YES, they can - then why such a restriction of not reading such files in reverse?
Some manuals I've looked at
Your thoughts please. |
|
| Back to top |
|
 |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
1.
the first question is easy. if you are at the end of a variable length record,
how far do you back-up to find the begining?
with fixed length records, it is easy, you know the length of the record.
2.
why can't you do it on dasd? probably,
because there are a million (ok, 2 or 3 anyway)
ways to resort the file back to front - and there it does not matter if it is VB or not.
just a guess,
but i imagine the tape is not reading byte per byte in reverse,
it is just deblocking (record addressing) from end of buffer to beginning.
you can read VSAM RRN in reverse. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10872
Location: italy
|
|
|
|
one of the reasons why read backward is supported for tapes is the existence of a read backward CCW op code x'0c'
IIRC from some tape subsytems up the read backward was substituted by a read previous
I' ll look if I can find some links about its specifications ! |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
In ASSEMBLER, it IS possible to read dasd PS files backwards - by way of the BSP macro. From the z/OS DFSMS Using Data Sets Manual:
The BSP macro backspaces one block on the magnetic tape or direct access volume being processed. The block can then be reread or rewritten. An attempt to rewrite the block destroys the contents of the remainder of the tape or track. See "Using the BSP Macro to Backspace a Physical Record" in topic 3.8.7.3 for information on using the BSP macro to process PDSEs.
The direction of movement is toward the load point or the beginning of the extent. You can not use the BSP macro if the track overflow option was specified or if the CNTRL, NOTE, or POINT macro is used. The BSP macro should be used only when other device control macros could not be used for backspacing.
Any attempt to backspace across the beginning of the data set on the current volume results in return code X'04' in register 15, and your tape or direct access volume is positioned before the first block. You cannot issue a successful backspace command after your EODAD routine is entered unless you first reposition the tape or direct access volume into your data set. CLOSE TYPE=T can position you at the end of your data set.
You can use the BSP macro to backspace VSE tapes containing embedded checkpoint records. If you use this means of backspacing, you must test for and bypass the embedded checkpoint records. You cannot use the BSP macro for VSE 7-track tapes written in translate mode. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10872
Location: italy
|
|
|
|
| Quote: |
| In ASSEMBLER, it IS possible to read dasd PS files backwards - by way of the BSP macro |
/mild disagreement on
the bsp is a media position command
the data movement will take place in the natural direction of the media
to read backwards continuosly somebody should ..
position at end of file
BSP one block read one block for the last one
after that
BSP two blocks read one block and so on
the read backward CCW for tapes will take place with the tape moving in reverse 
the only thing that I do not remember right now is the buffer <thing>
to use the address of the end of the buffer and data in the right orientation
or use the beginning addres and have the data filled in reverse order
I' ll have to check
file 524 at cbttape.org has all the samples of tape excp processing
backward read includes |
|
| Back to top |
|
|
Michael Mays
New User
Joined: 05 May 2010
Posts: 6
Location: Farmington Hills, MI
|
|
|
|
The REVERSED option was originally designed for tape processing.
When reading normally, the tape would be read sequentially from the beginning, then have to be high-speed rewound when it reached the end before it could be put away, and the drive re-used.
Sorting the tape required that it be read, sorted, re-written, and read again - A very long process.
Read REVERSED simply allowed the tape to be spun to the end at the same speed as a rewind, then read from the end to the beginning - No more time than reading normally, but read from the end of the file, to the beginning. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
Thanks Dick.
| dbzTHEdinosauer wrote: |
| the first question is easy. if you are at the end of a variable length record, how far do you back-up to find the begining? |
Well, in a way I understand this comment but other way, I haapen not to understand it.
Even for fixed-length records, how does the system (MVS/zOS) understand the "length of data to be read"? Please direct me to some manual where, probably, I'd be able to understand "what happens under the cover when READ is issued in COBOL and then from that perspective READ in any language".
| Quote: |
| you can read VSAM RRN in reverse. |
Yes, that one point to keep; as DASD is only media VSAM can reside on so yes, DASD-file is read in reverse when we read a VSAM RRN. But then tapes are essentially sequential, probably question still remains, as to why QSAM files are not read in reverse order... |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Dear Screwed Up!,
When the OPEN instruction is issued, there are control blocks populated from information provided by:- Select, FD statements, record descriptions
- DD statements
- catalogue entries
which provide the name, dcb parms,... etc - which means after you have OPENed (actually earlier), you know the record length. In the case of fixed length records, the record length is consistant and you know what it is. Variable length records have their length provided by a Variable Length Indicator - first part of each record. If you are at the end of a variable length record, you have no idea what the length of the record is.
Fast-tools Inc. |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
Suppose you have a physical block containing variable length records as follows:
| Code: |
----+----1----+----2----+----3----+----4----+----5----+----6----
ABCDEFGH IJKL MNOPQRST UVWX YZABCDEF GHIJ
04000100DCCDDC4F0300CCCC0100DCCDDC4F0100CCCC0100DCCDDC4F0000CCCC
0000040095369401000012340400953694020C00123404009536940308001234 |
Now, reading from the END backwards, tell me where the last record starts. Is it position 57 or position 45?
As to why QSAM files on DASD cannot be read in reverse DIRECTLY is because the disk platter spins in only one direction while TAPE travels both forward and backwards. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10872
Location: italy
|
|
|
|
for low level programming ...
in a read backwards the address provided must point to the end of buffer.
( most probably for high level languages, the IO modules will shift things around a bit)
for recfm fixed there is no issue, the records will be in the proper position.
with <automatic> error handling for short blocks ( bits settings in the DCB )
for recfm variable anyway the ccw read count will always be the largest blksize specified
no <automatic> error handling for short blocks ( there are no short blocks in a Variable length dataset )
and some demangling must be done using the DCB residual byte count (*) to position properly to the beginning of the data |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Also keeping in mind that the system reads physical records (blocks) while the cobol application reads/returns logical records. . . |
|
| Back to top |
|
|
|
|
