HP3000-L Archives

June 2012, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tony Summers <[log in to unmask]>
Reply To:
Tony Summers <[log in to unmask]>
Date:
Tue, 19 Jun 2012 14:42:55 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (57 lines)
I will email you (offline) a document I am working on that might answer your question.    The document is a high level  proposal on how we intend to retain access to MPE file types now that we have migrated over to MPUX and AcuCobol sitting on top of HPUX.  

(Actually,  you need a bit more history - currently the version of Acucobol we're using assumes "MPE"/"MPUX" is the default file system, so we had to do nothing to our programs to migrate them from the HP3000 to HPUX in Dec 2008.  We now intend to switch to a slightly different build of Acucobol,  which will no longer automatically recognise MPE file types.  However, we can - if required - retain access to mpux files by switching to the lower level intrinsics). 

I still have to type up the more detailed technical specification,  but in a nut-shell the Macros described in the document will link to an internal, bespoke, file handler (i.e. written in COBOL using HPFOPEN etc) that accesses the file at the intrinsic level.   The beauty of my proposal is that the calling applications themselves don't have to change that much - for example you simply change the "OPEN OUTPUT MYFILE" line to a Macro call "%HPOPEN(MYFILE#,OUTPUT#).  


-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf Of Edwin Clements
Sent: 19 June 2012 14:22
To: [log in to unmask]
Subject: Re: [HP3000-L] Cobol: Cobol and HPFOPEN

I don't know how important it is to you to use these intrinsics, but if it was me I would just do plain old COBOL Open and Close statements, right out of the COBOL manual.  They always worked for me for about anything I needed.  I have always considered using those intrinsics as doing it the hard way, unnecessarily, unless there is just some reason that you absolutely cannot use the COBOL statements, and I don't recall any situation like that where it just had to be done that way.  


________________________________
 From: John Pollard <[log in to unmask]>
To: [log in to unmask]
Sent: Tuesday, June 19, 2012 9:15 AM
Subject: [HP3000-L] Cobol: Cobol and HPFOPEN
 
I'm working on a small project. The idea is to write a Cobol program that can open (and read from and write to) most file types without hard-coding file information into the program. To do that, I chose to use intrinsics to open, read, and write data. To oversimplify: the program would open an input file, create an output file with the same characteristics as the input file, then write some, all (or none) of the input records to the output file.

I've run into a couple of problems that I can't seem to find answers to, and I'm hoping someone can educate me. 

1.) Variable record length files. I tried opening a variable record length Cobol source file created by Editor, creating a new variable length output file, and writing the input records to the output file. I got most of what I wanted, but was unable to reproduce the same "file limit" for the output file as I had in the input file (I wound up with the "limit" equal to the end-of-file). I thought the file limit would be set using HPFOPEN item 35, which says: "For variable-length records, the capacity is expressed in blocks (blockitem#=recordsize * blockfactor)". I can't seem to find any input file information that fits that formula and produces an output file limit that matches the input file limit.

2.) KSAM files. My first attempt used a native mode KSAM file as input. When I try to open the output file using HPFOPEN, I get an error; the "status.info" returns a -183. I used the program ERR.PUB.TELESUP to try to determine the meaning of that error, which it says is "RECORD DOES NOT CONTAIN ALL KEYS  (FSERR 183)". Usually when I get that error in a typical Cobol program it's because I tried to write a record that was too short, and it truncated some of the key data. But this error is occurring when I try to open the output file and the output record length seems to be the same as the input record length (when I let the program create a flat output file from the KSAM input file, the output record length matches the input record length and all the data appears to get successfully written).

[I got the KSAM key information using the FLABELINFO intrinsic on the input file. I checked the key definitions I received from FLABELINFO and they appear to be correct. Then I used HPFOPEN item 54 to pass that same KSAM key info to the new output KSAM file.]

3.) Should I consistently set the output "file code" to match the input "file code"? Are there some input characteristics that I should not try to set for the output file?

4.) Are there any "gotcha's" that I should be aware of for this project? 

5.) Indirectly related to this project is the fact that I can no longer find documentation for the HP3000. I was not keeping up with events for a couple of years, and my old Internet Explorer links to documentation at an HP web site became unusable. I have managed, on occasion, to find a couple of PDF files with useful documentation, but my library is still missing some "manuals". Is there a site where I can find all the HP3000 documentation - presumably PDF files of that documentation? Among other things, I was hoping there was some better info on error 183 when opening KSAM files (I can't find anything in the Intrinsics manual).

From a SHOWME: RELEASE: C.75.00   MPE/iX HP31900 C.45.05   USER VERSION: C.75.00

From a compile: COBOL II/iX   HP31500A.04.21  [85]

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

The contents of this email are confidential to the intended recipient and may not be disclosed. Although it is believed that this email and any attachments are virus free, it is the responsibility of the recipient to confirm this.

Details of Smith & Williamson group companies and Nexia Smith & Williamson Audit Limited and their regulators (where applicable), can be found at this URL

http://www.smith.williamson.co.uk/disclosure

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2