The Select "Assign To" processing negatively impacts GnuCOBOL EXTFH.
Only one type of the assign clause works a little bit - IBM
There are 3 panels below depicting the results of referencing
the pointer in the FCD-FILENAME-ADDRESS.
Only type IBM had the FCD-FILENAME-ADDRESS populated with anything close to correct.
I can code around the FCD-FILENAME-ADDRESS pointing at the object of the ASSIGN to CLAUSE instead of the expected PC file name.
However if any other Windows user attempts to use EXTFH it won't work - period.
It been over a year since I tried to get the ASSIGN TO clause remedied.
I contracted with Edward (and paid him) to fix the defect - he left the project before it could be finished.
There have been a couple attempts to fix this defect but generally those attempts only made the situation worse.
I can look in the JES dispatcher for Job Name + Step Name + Proc STEP + DD name and find the data set(s) associated with the DDNAME.
Move that value to a local variable and SET FCD-FILE-NAME-ADDRESS to the address of the populated local variable.
I already do a work around(s) for the ASSIGN TO clause defect.
I have supplied several test cases to Simon and Edward.
It just doesn't get fixed -
Because it is Windows is perhaps the problem ?
I cannot hard code the PC file name into ASSIGN to FILE-DATASET-NAME.
MOVE 'UHC.PART2.VSAM.PREMIUM' to FILE-DATASET-NAME is not a solution.
This makes no sense.
Somehow Ron's code works on Linux
What is the secret ? Or is this so low a priority defect (because it is Windows) and thus will never be remedied ?
I can vector all GnuCOBOL I-O thru the EXFH mechanism but that is a whole helluva lot of work for me.
Any chance that this can be fixed within a weeks time ?
I have spent a bunch of hours (100's) chasing this defect down.
There are bug reports for ASSIGN TO CLAUSE defects.
No need to create a bug report for EXTFH.
The Select "Assign To" processing negatively impacts GnuCOBOL EXTFH.
Only one type of the assign clause works a little bit - IBM
There are 3 panels below depicting the results of referencing
the pointer in the FCD-FILENAME-ADDRESS.
Only type IBM had the FCD-FILENAME-ADDRESS populated with anything close to correct.
I can code around the FCD-FILENAME-ADDRESS pointing at the object of the ASSIGN to CLAUSE instead of the expected PC file name.
However if any other Windows user attempts to use EXTFH it won't work - period.
It been over a year since I tried to get the ASSIGN TO clause remedied.
I contracted with Edward (and paid him) to fix the defect - he left the project before it could be finished.
There have been a couple attempts to fix this defect but generally those attempts only made the situation worse.
I can look in the JES dispatcher for Job Name + Step Name + Proc STEP + DD name and find the data set(s) associated with the DDNAME.
Move that value to a local variable and SET FCD-FILE-NAME-ADDRESS to the address of the populated local variable.
I already do a work around(s) for the ASSIGN TO clause defect.
I have supplied several test cases to Simon and Edward.
It just doesn't get fixed -
Because it is Windows is perhaps the problem ?
I cannot hard code the PC file name into ASSIGN to FILE-DATASET-NAME.
MOVE 'UHC.PART2.VSAM.PREMIUM' to FILE-DATASET-NAME is not a solution.
This makes no sense.
Somehow Ron's code works on Linux
What is the secret ? Or is this so low a priority defect (because it is Windows) and thus will never be remedied ?
I can vector all GnuCOBOL I-O thru the EXFH mechanism but that is a whole helluva lot of work for me.
Any chance that this can be fixed within a weeks time ?
I have spent a bunch of hours (100's) chasing this defect down.
There are bug reports for ASSIGN TO CLAUSE defects.
No need to create a bug report for EXTFH.
Please advise.
Thanks,
Ralph
Last edit: Ralph Linkletter 2021-06-16
Can you give me an example of the SELECT ... ASSIGN TO syntax that is not working?
Should work now with 3.2-dev.