Conference clt::cobol

>    So I tried to create a file on tape without success.  I get:
    
    What ltf command line did you use initialize the tape?

I didn't use ltf.  I don't know that will do anything to help.  Will it?  I just
tried initializing it.  From what I can tell, you have to use -c, -H, -t, -x or
-i along with another qualifier.  I think I want -O (omits usage of optional
headers) and now it is really hosed.

Even if I can get the tape to work by some combination of init and whatever,
that still won't help the customer. He is reading tapes created on an IBM.  It
needs to be kinda like the VMS mount/foreign command.

>I didn't use ltf.  I don't know that will do anything to help.  Will it?  I just

>Even if I can get the tape to work by some combination of init and whatever,
>that still won't help the customer. He is reading tapes created on an IBM.  It
>needs to be kinda like the VMS mount/foreign command.
    
    The DEC COBOL RTL supports tape handling only for those tapes
    initialized with ltf as ANSI labeled tapes.
    
    If you need to work with a tape intialized some other way, you will
    need to use other DIGITAL UNIX utilities to read/write the tape to/from
    a disk file that can be processed with DEC COBOL.
    
******************************
CLT::CLT$LIBRARY:[DEC_COBOL]DEC_COBOL_RN_V24.TXT;1

     V2.4-863      [Digital UNIX] You must use ltf (logical tape facility)
                   as supplied on a Digital UNIX V3.0 or higher system to
                   initialize ANSI labeled magtapes.

>>******************************
>>CLT::CLT$LIBRARY:[DEC_COBOL]DEC_COBOL_RN_V24.TXT;1

>>     V2.4-863      [Digital UNIX] You must use ltf (logical tape facility)
>>                   as supplied on a Digital UNIX V3.0 or higher system to
>>                   initialize ANSI labeled magtapes.

I saw that, however I did not read that to mean that DEC COBOL *only* supports
ANSI labeled tapes.  I read it to mean that if you want to create an ANSI
labeled tape, then use ltf first.  Perhaps it should also say you can only
create ANSI labeled tapes through DEC COBOL.  Which is too bad. This customer is
trying real hard to stick with DEC COBOL, but he keeps hitting one road block
after another. This particular application (critical app) is build around
processing tapes created on other platforms, mostly IBM.  

He can (and  would not necessarilty mind) pulling the files off tape using the
dd command, however, then he has the same problem I reported in note 3210 for
him.  The workaround offered works in some cases but apparently not all cases
with his real files which are quite large.  I suggested that he use C for now to
process the files which is working ok for him.  But that is posing another
problem, that is they have (in his words) a lot of useless COBOL code and he has
to re-invent the wheel. 

Thanks,

elin

If the tape isn't labeled, then don't describe it as a tape to COBOL and
everything should work.  (i.e. leave off assign to reel - just assign
it to /dev/rmt0h, and take out the value of id thing, or the RTL will
replace the rmt0h with the value of id string...).

It works for me.

The 'assign to reel' syntax is there specifically to describe ANSI labeled 
tapes, which requires all sorts of nasty machinations in the rtl.

Thanks Craig, yes that works great.  However, I don't believe it will do much
for the customer since he will be reading EBCDIC tapes created on an IBM
containing the header/data/trailer stuff.  Since I cannot create a tape with
multiple files from within COBOL, I am assuming that he will not be able to read
them either.  

cobol: Warning: tape.cob, line 9: CLOSE NO REWIND also requires ASSIGN TO
REEL/UNIT for use with magnetic tapes
    SELECT HEADER-FILE
-----------^
cobol: Warning: tape.cob, line 13: OPEN NO REWIND also requires ASSIGN TO
REEL/UNIT for use with magnetic tapes
    SELECT DATA-FILE
-----------^
cobol: Warning: tape.cob, line 13: CLOSE NO REWIND also requires ASSIGN TO
REEL/UNIT for use with magnetic tapes
    SELECT DATA-FILE
-----------^
cobol: Warning: tape.cob, line 17: OPEN NO REWIND also requires ASSIGN TO
REEL/UNIT for use with magnetic tapes
    SELECT TRAILER-FILE
-----------^

I'll keep digging.

thanks,
elin

Re .6

>   Thanks Craig, yes that works great.  However, I don't believe it will do much
>   for the customer since he will be reading EBCDIC tapes created on an IBM
>   containing the header/data/trailer stuff.  Since I cannot create a tape with
>   multiple files from within COBOL, I am assuming that he will not be able to read
>   them either.  

     I don't know about Digital UNIX handling of magtapes. However, the
     "header/data/trailer stuff" on an IBM magtape is actually three files.
     The header contains three 80-column card-images. These contain
     identifying information about the user's data file. The data is of 
     course the user's data file. The trailer contains two 80-column card-
     images which contain a little redundant identifying information and
     information about record and block counts for the user data.

     If the IBM user declares LABEL RECORDS STANDARD for his data file in the
     COBOL program that creates it, the program writes out these three files
     under the OPEN, WRITE and CLOSE verbs for the one user data file. Likewise, 
     a retrieval program in IBM COBOL will declare LABE RECORDS STANDARD and 
     this program will read these three files as if they were one file. If the 
     IBM user wants to deal with the three files individually, he sets up
     three FDs, one for each file and declares LABEL RECORDS OMITTED for each.
     Then he writes serial processing for OPEN, record-access-verb, CLOSE
     for each file in succession. When the user runs this program with LABEL 
     RECORDS OMITTED, he mounts the magtape and lets the system do its thing. 
     The idea is that after an IBM system closes each file it will position its 
     tape drive to the beginning of the next file . FWIW it also works this way 
     under OpenVMS VAX and Alpha, and it most likely works this way on Digital 
     UNIX. IBM essentially wrote the Bible on this kind of magtape handling 
     ages ago (mid-1960's) and it is a defacto industry standard. I would
     guess that you just need to stretch Craig's answer a little bit.

I suspect the tapes are IBM labelled.  There are two possible tape
label formats to be encountered:

1.  ANSI labelled
2.  IBM  labelled

and, of course:

3.  unlabelled

I think this thread shows that 1 & 3 are not true.  Therfore,
the tapes must have IBM labels on them.

DEC COBOL does not support #2.

There's probably a way to dump the first 80 bytes to read the
first label (dd?). I think there's a field defined in there that
specifies "A" for ANSI.    I think the tape header formats
are defined in the docset somewhere.

try ltf -tv

 v     Displays long form information about volume and files.  Normally, ltf
        operates with little terminal output.
 
The VOL1 label will be intreprted.  However, ltf works on ANSI volumes
only, so not sure just what will happen.  

Here is a view of the VOL1 label (ANSI):

typedef struct _VOL1_LABEL
{

  char label_id[4] ;           /* VOL1 label identifier           */
  char volume_id[6] ;          /* Volume Identifier      */  char access ;                /* Access field                    */
  char reserved1[26] ;         /* reserved for future use         */
  char owner_id[14] ;          /* Owner Identifier                */
  char reserved2[28] ;         /* reserved for future use         */
  char ANSI_version ;          /* ANSI tape version               */

} Cob_VOL1_Label ;


The last byte is expected to be a 3 or 4.

I don't know what an IBM label looks like, but it likely won't match
the above.

The next label starts with 4 bytes containing "HDR1".  If not, the error 
message in .0 will occur.