1 2OS/390 is IBM's follow-on to MVS and includes a POSIX, XOPEN, 3XPG4, build environment, a Unix-style filesystem (called HFS), and 4a POSIX (Born) shell. This port uses this environment and is a fairly 5straight-forward port of ZIP's Unix port - but uses the existing EBCDIC 6code. This port does not work with non-HFS (traditional MVS) 7filesystems. 8 9I believe all my changes are isolated with #ifdef's. 10 11Here's some text which might be useful for an OS390 README or 12the manual. 13 14ZIP for OS390 HFS datasets 15-------------------------- 16Allows you to create ZIP archives from the OS/390 OpenEdition 17command prompt. This port uses standard Unix-style I/O routines 18and only works with HFS files. 19 20Usage 21----- 22By default, ZIP does not perform character-set translation, but has 23options to make it easy to convert text files to be compatible with 24other systems 25 zip zipfile list # add the files in 'list' to archive 'zipfile' 26 zip -a zipfile list # same as above, but translate files to ASCII 27 zip -al zipfile list # same as above, translate linefeeds to DOS style 28 zip -all zipfile list # same as '-a', translate linefeeds to UNIX style 29 30Build process 31------------- 32Assuming GNU make is available in your path and is called "gmake" (See 33the notes on Makefile changes below) and a C compiler is available as 34"cc", then type 35 gmake -f unix/Makefile MAKE=gmake os390 36 37If GNU make is not available, the existing makefile can create zip, but will 38error on the other executable (zipsplit, zipcloak, zipnote) if you type 39 make -f unix/Makefile os390 40 41Overview of Changes 42------------------- 43The OS/390 port is treated as a variant of the Unix port. EBCDIC support 44was already implemented for CMS/MVS-batch ports. The specific changes I 45made are summarized below. 46 47unix/Makefile - zip uses a unusual _.o target which IBM's make can't handle. 48Since the Makefile has a macro called MAKE that is used for a recursive 49call to make, I changed the MACRO to call "gmake" - GNU's make - which 50can handle the _.o target. If you don't have GNU make, you can 51workaround by manually applying symlinks from whatever.c to whatever_.c. 52Alternatively, the whatever_.o files could be explicitely added for os390. 53 54I added an os390 target with appropriate defines. 55 56zipup.c - added code (#ifdef OS390) to convert test to ASCII if -a flag 57was set. 58 59zip.c - changed logic which always used DOS-style newlines when -a was 60set to be consistent with other port (DOS newlines if -l option) 61 62zipfile.c - miscellaneous changes to force storing file names and 63descriptions in ASCII in the zip directory. This makes zip files 64portable across all platforms. This in turn meant names did not 65need to be translated when displaying messages. 66 67zip.h - strtoasc was missing a closing parenthesis. 68 69ebcdic.h - changed translation table to be consistent with current IBM 70recommendations - exact same changes to ebcdic.h as in my unzip port. 71 72tailor.h - define huge/far/near to be empty 73 74unix/unix.c - substantial changes to deal with mode flags. Under 75the current XOPEN standards, some of the traditional unix file mode 76bits need not be in fixed locations, but standard access macros must be 77available to access the values. The old unix.c code just picked up these 78values and saved them as-is where unzip interpreted them. Existing 79Unix system provided the macros for XOPEN compliance, but left the flags 80in their traditional locations. OS/390 has a brand new filesystem which 81is XOPEN compliant without revealing the positions of these flags. 82To create the bitmask in the same format unzip expects, the macros are 83tested one-by-one to set the appropriate bits. This same logic should 84work on any XOPEN system, but takes more instructions (I did test this 85logic on Linux). 86