Opening a file for out when External File Mapper is used

In our legacy (Net Express 3.1) code we defined our input/output files as follows:

SELECT LOGIN ASSIGN TO DISK FROM LocLogin

ORGANZATION IS LINE SEQUENTIAL

LOCK MODE IS MANUAL WITH LOCK ON RECORDS 

FILE STATUS IS FILE-STATUS

ACCESS IS SEQUENTIAL.

In moving to Visual COBOL this no longer worked and we were advised to use the External File Mapper (SupportLine Incident #2539016 ). We did and can open files using this setup.  However, I have two issues I need some help with.  Issue #1 is that if there is a file error, I don't have the file path available to report it.  For example, EMLocLogin would be defined in the External Mapper File but it is not available at runtime; so so I need to open the External File Mapper File and read for EMLocLogin to get my file path?  Issue #2, I need to be able to open a report file (output) whose name will be dynamic, that is, it is named for the particular USERID running it, for example C:\AIRRS\REPORTS\JPL0457.135 (JPL0457 = USERID), so the actual file path would be moved to RptLocation in working storage as shown in the select below:

SELECT RPT-FILE ASSIGN TO DISK FROM RptLocation

ORGANIZATION IS LINE SEQUENTIAL

ACCESS IS SEQUENTIAL

FILE STATUS IS FILE-STATUS.

Since I have to use External File Mapper, how can I set the path of the report file dynamically based upon which user is running it? 

I have reviewed the PrintTextVC solution found here in the forum and it will be very helpful when it comes time to print, but I've got to create the file first.  Thanks in advance, I realize it is probably an elementary question but the migration seems to be full of simple questions I have a hard time answering.

 

 

  • Verified Answer

    I believe that maybe you were not given the best advice in the support incident for this.

    I tested your program using original syntax in both native code and in managed code and although it works fine in native code (same as it did in NX 3.1) it causes a compiler error in managed code. I will create a new support incident for this and report this as a bug .

    The problem seems to lie in the phrase:

      ASSIGN TO DISK FROM LocLogin

    You can get the same behavior by using:

     ASSIGN TO DYNAMIC LocLogin

    or just

     ASSIGN TO LocLogin

    because by default the ASSIGN directive is set to ASSIGN"DYNAMIC" which treats the ASSIGN as though DYNAMIC were turned on.

    If LocLogin is then defined in working-storage and assigned a value that is the name that would be assigned to the physical filename.

    Although using the external file mapper will work to assign your physical files to the logical filenames in your application, I think that the workaround that I propose here will solve both of the issues that you report in this post.

    Thanks.

  • Chris, you are correct as always.  This would have sped up the conversion quite a bit, so glad you are around.

    Bud.

  • Chris, you are correct as always.  This would have sped up the conversion quite a bit, so glad you are around.

    Bud.

  • Chris, you are correct as always.  This would have sped up the conversion quite a bit, so glad you are around.

    Bud.